json schema
ved equals() and hashCode implementations
ขณะนี้ไลบรารีนี้อยู่ในโหมดการบำรุงรักษาและแทนที่ด้วย erosb/json-sKema
พื้นที่เก็บข้อมูลนี้และจะไม่เห็นคุณสมบัติใหม่ใดๆ ให้การสนับสนุนที่มั่นคงสำหรับข้อกำหนด JSON Schema เวอร์ชันร่าง 04, ร่าง 06 และร่าง 07
ร่างล่าสุดปี 2020-12 รองรับโดย erosb/json-sKema เท่านั้น
โปรเจ็กต์นี้เป็นการนำข้อกำหนด JSON Schema Draft v4, Draft v6 และ Draft v7 ไปใช้ ใช้ org.json API (สร้างโดย Douglas Crockford) เพื่อแสดงข้อมูล JSON
สมมติว่าคุณรู้อยู่แล้วว่า JSON Schema คืออะไร และคุณต้องการใช้ในแอปพลิเคชัน Java เพื่อตรวจสอบความถูกต้องของข้อมูล JSON แต่อย่างที่คุณอาจค้นพบแล้ว ยังมีการใช้งาน Java อื่นๆ ของข้อกำหนด JSON Schema ต่อไปนี้เป็นคำแนะนำบางส่วนว่าควรใช้อันไหน:
เพิ่มการพึ่งพาต่อไปนี้ให้กับ pom.xml ของคุณ:
< dependency >
< groupId >com.github.erosb</ groupId >
< artifactId >everit-json-schema</ artifactId >
< version >1.14.4</ version >
</ dependency > หมายเหตุเกี่ยวกับเวอร์ชันเก่า : เวอร์ชันระหว่าง 1.6.0 ถึง 1.9.1 สามารถพบได้บน JitPack ที่มีพิกัด com.github.everit-org.json-schema:org.everit.json.schema เท่านั้น เวอร์ชัน 1.0.0 ... 1.5.1 มีอยู่ใน Maven Central ภายใต้พิกัด org.everit.json:org.everit.json.schema
มีความพยายามสองสามครั้งในการทำให้ไลบรารี่ทำงานบน Java 6/7
พอร์ต java6 เวอร์ชัน 1.9.2 ได้รับการพัฒนาโดย @mindbender1 และสามารถเข้าถึงได้ผ่าน Maven Central ด้วยพิกัดต่อไปนี้:
< dependency >
< groupId >com.github.erosb</ groupId >
< artifactId >everit-json-schema-jdk6</ artifactId >
< version >1.9.2</ version >
</ dependency >Backport ของเวอร์ชันเก่า:
com.doctusoft:json-schema-java7:1.4.1com.github.rdruilhe.json-schema:org.everit.json.schema:1.1.1 import org . everit . json . schema . Schema ;
import org . everit . json . schema . loader . SchemaLoader ;
import org . json . JSONObject ;
import org . json . JSONTokener ;
// ...
try ( InputStream inputStream = getClass (). getResourceAsStream ( "/path/to/your/schema.json" )) {
JSONObject rawSchema = new JSONObject ( new JSONTokener ( inputStream ));
Schema schema = SchemaLoader . load ( rawSchema );
schema . validate ( new JSONObject ( "{ " hello " : " world " }" )); // throws a ValidationException if this object is invalid
}ปัจจุบัน JSON Schema มี 4 รุ่นหลัก ได้แก่ Draft 3, Draft 4, Draft 6 และ Draft 7 ไลบรารีนี้ใช้งาน 3 รุ่นใหม่ คุณสามารถดูความแตกต่างได้อย่างรวดเร็วที่นี่และที่นี่ เนื่องจากทั้งสองเวอร์ชันมีความแตกต่างกันหลายประการ และร่าง 6 ไม่สามารถใช้งานร่วมกับร่าง 4 แบบย้อนหลังได้ จึงควรทราบว่าคุณจะใช้เวอร์ชันใด
วิธีที่ดีที่สุดในการแสดงถึงเวอร์ชัน JSON Schema ที่คุณต้องการใช้คือการรวม URL meta-schema ไว้ในรูทเอกสารด้วยคีย์ "$schema" นี่เป็นสัญลักษณ์ทั่วไปที่ห้องสมุดอำนวยความสะดวกในการพิจารณาว่าควรใช้เวอร์ชันใด
การอ้างอิงด่วน:
"$schema": "http://json-schema.org/draft-04/schema" ในรูทสคีมา ดังนั้น Draft 4 จะถูกนำมาใช้"$schema": "http://json-schema.org/draft-06/schema" ในรูทสคีมา ดังนั้น Draft 6 จะถูกใช้"$schema": "http://json-schema.org/draft-07/schema" ในรูทสคีมา ดังนั้น Draft 7 จะถูกใช้หากคุณต้องการระบุเวอร์ชัน meta-schema อย่างชัดเจน คุณสามารถเปลี่ยนค่าเริ่มต้นจาก Draft 4 เป็น Draft 6 / 7 ได้โดยการกำหนดค่าตัวโหลดด้วยวิธีนี้:
SchemaLoader loader = SchemaLoader . builder ()
. schemaJson ( yourSchemaJSON )
. draftV6Support () // or draftV7Support()
. build ();
Schema schema = loader . load (). build (); ตั้งแต่เวอร์ชัน 1.1.0 เครื่องมือตรวจสอบจะรวบรวมการละเมิดสคีมาทั้งหมด (แทนที่จะล้มเหลวทันทีในการละเมิดครั้งแรก) ความล้มเหลวแต่ละรายการจะแสดงด้วยตัวชี้ JSON โดยชี้จากรากของเอกสารไปยังส่วนที่ละเมิด หากตรวจพบการละเมิดสคีมามากกว่าหนึ่งรายการ ValidationException จะถูกส่งไปที่องค์ประกอบหลักที่พบบ่อยที่สุดของการละเมิด และการละเมิดแต่ละรายการสามารถรับได้โดยใช้เมธอด ValidationException#getCausingExceptions()
เพื่อสาธิตแนวคิดข้างต้น ให้ดูตัวอย่าง ลองพิจารณาสคีมาต่อไปนี้:
{
"type" : " object " ,
"properties" : {
"rectangle" : { "$ref" : " #/definitions/Rectangle " }
},
"definitions" : {
"size" : {
"type" : " number " ,
"minimum" : 0
},
"Rectangle" : {
"type" : " object " ,
"properties" : {
"a" : { "$ref" : " #/definitions/size " },
"b" : { "$ref" : " #/definitions/size " }
}
}
}
}เอกสาร JSON ต่อไปนี้มีการละเมิดสคีมาเพียงครั้งเดียว (เนื่องจาก "a" ไม่สามารถเป็นค่าลบได้):
{
"rectangle" : {
"a" : -5 ,
"b" : 5
}
} ในกรณีนี้ ValidationException ที่ถูกโยนออกมาจะชี้ไปที่ #/rectangle/a และจะไม่มีข้อยกเว้นย่อย:
try {
schema . validate ( rectangleSingleFailure );
} catch ( ValidationException e ) {
// prints #/rectangle/a: -5.0 is not higher or equal to 0
System . out . println ( e . getMessage ());
}ตอนนี้ เพื่อแสดงให้เห็นวิธีจัดการกับการละเมิดหลายครั้ง ลองพิจารณาเอกสาร JSON ต่อไปนี้ ซึ่งทั้งคุณสมบัติ "a" และ "b" ละเมิดสคีมาข้างต้น:
{
"rectangle" : {
"a" : -5 ,
"b" : " asd "
}
} ในกรณีนี้ ValidationException ที่ถูกโยนทิ้งจะชี้ไปที่ #/rectangle และมีข้อยกเว้นย่อย 2 ประการ โดยชี้ไปที่ #/rectangle/a และ #/rectangle/b :
try {
schema . validate ( rectangleMultipleFailures );
} catch ( ValidationException e ) {
System . out . println ( e . getMessage ());
e . getCausingExceptions (). stream ()
. map ( ValidationException :: getMessage )
. forEach ( System . out :: println );
}สิ่งนี้จะพิมพ์ผลลัพธ์ต่อไปนี้:
#/rectangle: 2 schema violations found
#/rectangle/a: -5.0 is not higher or equal to 0
#/rectangle/b: expected type: Number, found: String
ตั้งแต่เวอร์ชัน 1.4.0 เป็นต้นไป คุณสามารถพิมพ์อินสแตนซ์ ValidationException เป็นรายงานความล้มเหลวในรูปแบบ JSON ได้ วิธี ValidationException#toJSON() ส่งคืนอินสแตนซ์ JSONObject ด้วยคีย์ต่อไปนี้:
"message" : ข้อความยกเว้นที่เป็นมิตรต่อโปรแกรมเมอร์ (คำอธิบายของความล้มเหลวในการตรวจสอบ)"keyword" : คีย์เวิร์ด JSON Schema ที่ถูกละเมิด"pointerToViolation" : ตัวชี้ JSON แสดงถึงเส้นทางจากรูทเอกสารอินพุตไปยังแฟรกเมนต์ ซึ่งทำให้การตรวจสอบล้มเหลว"schemaLocation" : ตัวชี้ JSON แสดงถึงเส้นทางจากรูท schema JSON ไปยังคีย์เวิร์ดที่ถูกละเมิด"causingExceptions" : อาร์เรย์ของข้อยกเว้นย่อย (อาจว่างเปล่า) ข้อยกเว้นย่อยแต่ละรายการจะแสดงเป็นออบเจ็กต์ JSON โดยมีโครงสร้างเดียวกันกับที่อธิบายไว้ในรายการนี้ ดูเพิ่มเติมด้านบนเกี่ยวกับการทำให้เกิดข้อยกเว้น โปรดคำนึงว่ารายงานความล้มเหลวฉบับสมบูรณ์เป็น โครงสร้างแบบต้นไม้แบบลำดับชั้น : สามารถรับสาเหตุย่อยของสาเหตุได้โดยใช้ #getCausingExceptions()
ValidationListener สามารถตอบสนองวัตถุประสงค์ในการแก้ไขความกำกวมเกี่ยวกับ วิธีที่ อินสแตนซ์ JSON จับคู่ (หรือไม่ตรงกัน) กับสคีมา คุณสามารถแนบการใช้งาน ValidationListener เข้ากับเครื่องมือตรวจสอบเพื่อรับการแจ้งเตือนเหตุการณ์เกี่ยวกับผลลัพธ์ความสำเร็จ/ความล้มเหลวระดับกลาง
ตัวอย่าง:
import org . everit . json . schema . Validator ;
...
Validator validator = Validator . builder ()
. withListener ( new YourValidationListenerImplementation ())
. build ();
validator . performValidation ( schema , input );เหตุการณ์ที่รองรับในปัจจุบัน:
"$ref" ได้รับการแก้ไขแล้ว"allOf" / "anyOf" / "oneOf""allOf" / "anyOf" / "oneOf" ไม่ตรงกัน"if""if" ไม่ตรงกัน"then""then" ไม่สามารถจับคู่ได้"else""else" ไม่สามารถจับคู่ได้ ดู javadoc ของอินเทอร์เฟซ org.everit.json.schema.event.ValidationListener สำหรับรายละเอียดเพิ่มเติม คลาสเหตุการณ์เฉพาะยังมีการใช้งาน #toJSON() และ #toString() ที่เหมาะสม ดังนั้นคุณจึงสามารถพิมพ์ออกมาในรูปแบบที่สามารถแยกวิเคราะห์ได้ง่าย
ตามค่าเริ่มต้น การรายงานข้อผิดพลาดในการตรวจสอบความถูกต้องในโหมดการรวบรวม (ดูบท "การตรวจสอบความล้มเหลว") ซึ่งสะดวกสำหรับการมีรายงานข้อผิดพลาดโดยละเอียด แต่ในบางกรณี จะเหมาะสมกว่าที่จะหยุดการตรวจสอบเมื่อพบความล้มเหลวโดยไม่ตรวจสอบส่วนที่เหลือของเอกสาร JSON หากต้องการสลับโหมดการตรวจสอบที่ล้มเหลวอย่างรวดเร็วนี้
Validator สำหรับสคีมาของคุณอย่างชัดเจนแทนที่จะเรียก Schema#validate(input)failEarly() ของ ValidatorBuilderตัวอย่าง:
import org . everit . json . schema . Validator ;
...
Validator validator = Validator . builder ()
. failEarly ()
. build ();
validator . performValidation ( schema , input ); หมายเหตุ: คลาส Validator นั้นไม่เปลี่ยนรูปและปลอดภัยสำหรับเธรด ดังนั้นคุณไม่จำเป็นต้องสร้างคลาสใหม่สำหรับการตรวจสอบแต่ละครั้ง เพียงกำหนดค่าเพียงครั้งเดียวก็เพียงพอแล้ว
ในบางกรณี เมื่อตรวจสอบความถูกต้องของตัวเลขหรือบูลีน ควรยอมรับค่าสตริงที่สามารถแยกวิเคราะห์ได้เป็นค่าพื้นฐาน เนื่องจากการประมวลผลที่ต่อเนื่องใดๆ จะแยกวิเคราะห์ตัวอักษรเหล่านี้เป็นค่าตัวเลขและตรรกะที่เหมาะสมโดยอัตโนมัติด้วย นอกจากนี้ ค่าดั้งเดิมที่ไม่ใช่สตริงนั้นไม่สำคัญที่จะแปลงเป็นสตริง ดังนั้นทำไมไม่อนุญาตให้ใช้ค่าดั้งเดิมของ json เป็นสตริงล่ะ
ตัวอย่างเช่น ลองใช้สคีมานี้:
{
"properties" : {
"booleanProp" : {
"type" : " boolean "
},
"integerProp" : {
"type" : " integer "
},
"nullProp" : {
"type" : " null "
},
"numberProp" : {
"type" : " number "
},
"stringProp" : {
"type" : " string "
}
}
}เอกสาร JSON ต่อไปนี้ไม่ผ่านการตรวจสอบ แม้ว่าสตริงทั้งหมดสามารถแปลงเป็นค่าที่เหมาะสมได้อย่างง่ายดาย:
{
"numberProp" : " 12.34 " ,
"integerProp" : " 12 " ,
"booleanProp" : " true " ,
"nullProp" : " null " ,
"stringProp" : 12.34
}ในกรณีนี้ หากคุณต้องการให้อินสแตนซ์ด้านบนผ่านการตรวจสอบกับสคีมา คุณจะต้องเปิดการกำหนดค่าการตรวจสอบความถูกต้องเบื้องต้นแบบผ่อนปรน ตัวอย่าง:
import org . everit . json . schema .*;
...
Validator validator = Validator . builder ()
. primitiveValidationStrategry ( PrimitiveValidationStrategy . LENIENT )
. build ();
validator . performValidation ( schema , input );หมายเหตุ: ในโหมดการแยกวิเคราะห์แบบผ่อนปรน ตัวอักษรบูลีนที่เป็นไปได้ทั้งหมด 22 ตัวจะได้รับการยอมรับเป็นค่าตรรกะ
ข้อกำหนด JSON Schema กำหนดคีย์เวิร์ด "default" เพื่อแสดงถึงค่าเริ่มต้น แม้ว่าจะไม่ได้ระบุอย่างชัดเจนว่าจะส่งผลต่อกระบวนการตรวจสอบอย่างไร ตามค่าเริ่มต้นไลบรารีนี้ไม่ได้ตั้งค่าเริ่มต้น แต่หากคุณต้องการคุณสมบัตินี้ คุณสามารถเปิดใช้งานได้โดยวิธี SchemaLoaderBuilder#useDefaults(boolean) ก่อนที่จะโหลดสคีมา:
{
"properties" : {
"prop" : {
"type" : " number " ,
"default" : 1
}
}
} JSONObject input = new JSONObject ( "{}" );
System . out . println ( input . get ( "prop" )); // prints null
Schema schema = SchemaLoader . builder ()
. useDefaults ( true )
. schemaJson ( rawSchema )
. build ()
. load (). build ();
schema . validate ( input );
System . out . println ( input . get ( "prop" )); // prints 1 หากมีคุณสมบัติบางอย่างหายไปจาก input ที่มีค่า "default" ในสคีมา คุณสมบัติเหล่านั้นจะถูกตั้งค่าโดยเครื่องมือตรวจสอบระหว่างการตรวจสอบ
สำหรับการสนับสนุนคีย์เวิร์ด "regex" ของ JSON Schema ไลบรารีนำเสนอการใช้งานที่เป็นไปได้สองแบบ:
java.util.regex แม้ว่าไลบรารี RE2J จะให้ประสิทธิภาพที่ดีกว่า java.util.regex อย่างมาก แต่ก็เข้ากันไม่ได้อย่างสมบูรณ์กับไวยากรณ์ที่ java.util หรือ ECMA 262 รองรับ ดังนั้นจึงขอแนะนำ RE2J หากคุณกังวลเกี่ยวกับประสิทธิภาพและข้อจำกัดของไลบรารีนั้นเป็นที่ยอมรับได้
การใช้งาน RE2J สามารถเปิดใช้งานได้ด้วยการเรียก SchemaLoaderBuilder#regexpFactory() :
SchemaLoader loader = SchemaLoader . builder ()
. regexpFactory ( new RE2JRegexpFactory ())
// ...
. build ();หมายเหตุ:
pom.xml ของคุณ เพื่อที่จะได้ไม่เพิ่มขนาดของสิ่งประดิษฐ์ของคุณโดยไม่จำเป็นjava.util ใน 1.8.0 มีการใช้ RE2J และใน 1.9.0 เรากำหนดค่าได้ เนื่องจากการถดถอยที่รายงานบางส่วน ไลบรารีรองรับคีย์เวิร์ด readOnly และ writeOnly ซึ่งปรากฏครั้งแรกใน Draft 7 หากคุณต้องการใช้คุณสมบัตินี้ ก่อนการตรวจสอบ คุณจะต้องแจ้งให้ผู้ตรวจสอบทราบหากการตรวจสอบเกิดขึ้นในบริบทการอ่านหรือเขียน ตัวอย่าง:
สคีมา.json:
{
"properties" : {
"id" : {
"type" : " number " ,
"readOnly" : true
}
}
}ข้อมูลโค้ดตรวจสอบ:
Validator validator = Validator . builder ()
. readWriteContext ( ReadWriteContext . WRITE )
. build ();
validator . performValidation ( schema , new JSONObject ( "{ " id " :42}" )); ในกรณีนี้ เราแจ้งผู้ตรวจสอบความถูกต้องว่าการตรวจสอบเกิดขึ้นในบริบท WRITE และในออบเจ็กต์ JSON อินพุต คุณสมบัติ "id" จะปรากฏขึ้น ซึ่งทำเครื่องหมายเป็น "readOnly" ในสคีมา ดังนั้นการเรียกนี้จะส่ง ValidationException
เริ่มต้นจากเวอร์ชัน 1.2.0 ไลบรารีสนับสนุนคีย์เวิร์ด "format" (ซึ่งเป็นส่วนที่เป็นทางเลือกของข้อกำหนด)
รูปแบบที่รองรับจะแตกต่างกันไปขึ้นอยู่กับเวอร์ชันข้อมูลจำเพาะของสคีมาที่คุณใช้ (เนื่องจากรูปแบบมาตรฐานถูกนำมาใช้ในเวอร์ชันที่แตกต่างกันตามข้อกำหนดการตรวจสอบความถูกต้อง)
ตารางความเข้ากันได้ของรูปแบบมาตรฐานที่รองรับมีดังนี้
| ร่างที่ 4 | ร่างที่ 6 | ร่างที่ 7 | |
|---|---|---|---|
| วันที่-เวลา | |||
| อีเมล | |||
| ชื่อโฮสต์ | |||
| ไอพีวี4 | |||
| ไอพีวี6 | |||
| ยูริ | |||
| การอ้างอิง uri | |||
| uri-เทมเพลต | |||
| json-ตัวชี้ | |||
| วันที่ | |||
| เวลา | |||
| นิพจน์ทั่วไป | |||
| ญาติ-json-ตัวชี้ |
ไลบรารียังรองรับการเพิ่มเครื่องมือตรวจสอบรูปแบบที่กำหนดเอง หากต้องการใช้เครื่องมือตรวจสอบที่กำหนดเองโดยพื้นฐานแล้ว คุณต้องทำ
org.everit.json.schema.FormatValidatororg.everit.json.schema.loader.SchemaLoader.SchemaLoaderBuilder ก่อนที่จะโหลดสคีมาจริงสมมติว่างานคือการสร้างเครื่องมือตรวจสอบแบบกำหนดเองซึ่งยอมรับสตริงที่มีอักขระจำนวนคู่
FormatValidator แบบกำหนดเองจะมีลักษณะดังนี้:
public class EvenCharNumValidator implements FormatValidator {
@ Override
public Optional < String > validate ( final String subject ) {
if ( subject . length () % 2 == 0 ) {
return Optional . empty ();
} else {
return Optional . of ( String . format ( "the length of string [%s] is odd" , subject ));
}
}
} หากต้องการผูก EvenCharNumValidator กับค่า "format" (เช่น "evenlength" ) คุณต้องผูกอินสแตนซ์ตัวตรวจสอบกับคีย์เวิร์ดในการกำหนดค่าตัวโหลดสคีมา:
JSONObject rawSchema = new JSONObject ( new JSONTokener ( inputStream ));
SchemaLoader schemaLoader = SchemaLoader . builder ()
. schemaJson ( rawSchema ) // rawSchema is the JSON representation of the schema utilizing the "evenlength" non-standard format
. addFormatValidator ( "evenlength" , new EvenCharNumValidator ()) // the EvenCharNumValidator gets bound to the "evenlength" keyword
. build ();
Schema schema = schemaLoader . load (). build (); // the schema is created using the above created configuration
schema . validate ( jsonDocument ); // the document validation happens here ในเอกสาร JSON Schema คุณสามารถใช้ URI แบบสัมพันธ์เพื่ออ้างอิงประเภทที่กำหนดไว้ก่อนหน้านี้ การอ้างอิงดังกล่าวแสดงโดยใช้คำหลัก "$ref" และ "$id" แม้ว่าข้อกำหนดจะอธิบายการเปลี่ยนแปลงขอบเขตการแก้ไขและการลดการอ้างอิงโดยละเอียด แต่ก็ไม่ได้อธิบายลักษณะการทำงานที่คาดหวังเมื่อ "$ref" หรือ "$id" ที่เกิดขึ้นครั้งแรกเป็น URI แบบสัมพัทธ์
ในกรณีของการดำเนินการนี้ เป็นไปได้ที่จะกำหนด URI สัมบูรณ์ที่ทำหน้าที่เป็น URI พื้นฐาน (ขอบเขตการแก้ไข) อย่างชัดเจนโดยใช้วิธีสร้างที่เหมาะสม:
SchemaLoader schemaLoader = SchemaLoader . builder ()
. schemaJson ( jsonSchema )
. resolutionScope ( "http://example.org/" ) // setting the default resolution scope
. build (); เมื่อสคีมาของคุณเติบโตขึ้น คุณจะต้องแยกออกเป็นไฟล์ต้นฉบับหลายๆ ไฟล์และโยงไฟล์เหล่านั้นด้วยการอ้างอิง "$ref" หากคุณต้องการจัดเก็บสคีมาบน classpath (แทน เช่น การให้บริการผ่าน HTTP) วิธีที่แนะนำคือใช้โปรโตคอล classpath: เพื่อให้สคีมาอ้างอิงถึงกัน วิธีทำให้ classpath: protocol ทำงาน:
SchemaClient ที่รับรู้ classpath-aware ในตัวของไลบรารีได้ ตัวอย่าง: SchemaLoader schemaLoader = SchemaLoader . builder ()
. schemaClient ( SchemaClient . classPathAwareClient ())
. schemaJson ( jsonSchema )
. resolutionScope ( "classpath://my/schemas/directory/" ) // setting the default resolution scope
. build (); ด้วยการกำหนดค่านี้ การอ้างอิงต่อไปนี้จะได้รับการแก้ไขอย่างถูกต้องใน jsonSchema :
{
"properties" : {
"sameDir" : { "$ref" : " sameDirSchema.json " },
"absPath" : { "$ref" : " classpath://somewhere/else/otherschema.json " },
"httpPath" : { "$ref" : " http://example.org/http-works-as-usual " },
}
} และ sameDirSchema.json จะถูกค้นหาใน /my/schemas/directory/sameDirSchema.json บน classpath
บางครั้งการทำงานกับสคีมาที่โหลดไว้ล่วงหน้าก็มีประโยชน์ โดยเราจะกำหนด URI ตามอำเภอใจ (อาจเป็น uuid) แทนการโหลดสคีมาผ่าน URL ซึ่งสามารถทำได้โดยการกำหนดสคีมาให้กับ URI ด้วยเมธอด #registerSchemaByURI() ของตัวโหลดสคีมา ตัวอย่าง:
SchemaLoader schemaLoader = SchemaLoader . builder ()
. registerSchemaByURI ( new URI ( "urn:uuid:a773c7a2-1a13-4f6a-a70d-694befe0ce63" ), aJSONObject )
. registerSchemaByURI ( new URI ( "http://example.org" ), otherJSONObject )
. schemaJson ( jsonSchema )
. resolutionScope ( "classpath://my/schemas/directory/" )
. build ();หมายเหตุ:
JSONObject หรือ Boolean (ประเภทพารามิเตอร์ที่เป็นทางการคือ Object เท่านั้นเนื่องจากทั้งสองไม่มีซูเปอร์คลาสทั่วไปอื่นใด)SchemaClient ของคุณเองก็ใช้ได้ผลเช่นกัน หรือคุณสามารถใช้การจัดการโปรโตคอลที่ขยายได้ของแพ็คเกจ java.net ) การขึ้นต่อกันบางส่วนสามารถแยกออกจากไลบรารีได้ และยังคงใช้งานได้ โดยมีข้อจำกัดบางประการ:
com.damnhandy:handy-uri-templates สคีมาของคุณไม่ควรใช้รูปแบบ "uri-template"commons-validator:commons-validator สคีมาของคุณไม่ควรใช้รูปแบบต่อไปนี้: "email" , "ipv4" , "ipv6" , "hostname" ตามเวอร์ชันห้องสมุด:
javadoc ที่สร้างขึ้นในเวอร์ชัน 1.0.0 - 1.5.1 มีอยู่ที่ javadoc.io
สำหรับเวอร์ชันระหว่าง (1.6.0 - 1.9.1) จะไม่มีการเผยแพร่ที่ใดเลย
