أداة التحقق من مخطط JSON

الصق مخططًا ومستندًا، ثم اختر المسودة؛ ستقارن أداة التحقق المستند بكل كلمة مفتاحية يستخدمها مخططك، type، required، enum، oneOf، $ref، if/then/else، وformat المخصص، وتُبلغ عن كل مخالفة باستخدام مؤشر على نمط JSONPath يشير بدقة إلى الموقع المخالف.

كيفية التحقق وفقًا لمخطط

  1. 1

    الصق المخطط

    مسودة مخطط JSON رقم 04 أو 07 أو 2020-12؛ حيث تختار الكلمة المفتاحية `$schema` (إن وُجدت) المسودة المناسبة تلقائيًا.

  2. 2

    الصق المستند

    مستند JSON الذي ترغب في التحقق من صحته؛ يجب أن يكون JSON صالحًا أولًا، حيث تظهر أخطاء الصياغة قبل تقييم المخطط.

  3. 3

    تحقق من الصحة

    يتم الإبلاغ عن كل مخالفة باستخدام مؤشر JSON (`/user/email`) والكلمة المفتاحية التي فشلت (`format`، `required`، إلخ).

  4. 4

    صحّح وأعد التحقق

    عدّل أيًا من الجانبين، وستتحدّث الحالة مباشرةً.

الكلمات المفتاحية المدعومة

الأساسية: type، enum، const، multipleOf، maximum، minimum، exclusiveMaximum، exclusiveMinimum، maxLength، minLength، pattern، maxItems، minItems، uniqueItems، maxContains، minContains، maxProperties، minProperties، required، dependentRequired.

التركيب: allOf، anyOf، oneOf، not.

أدوات التطبيق: properties، patternProperties، additionalProperties، items، prefixItems، contains، propertyNames.

الشرطية: if، then، else، dependentSchemas.

المراجع: $ref، $defs، $id، $anchor.

الصيغ (مع التحقق منها عند تفعيلها): date-time، date، time، duration، email، hostname، ipv4، ipv6، uri، uuid، regex.

مخرجات الخطأ

FAIL  /user/email        format            "not-an-email" is not a valid "email"
FAIL  /user/age          minimum           -3 is less than the minimum 0
FAIL  /orders/0/total    type              "42" is not of type "number"
FAIL  /                  required          missing required property "shippingAddress"

يتضمن كل خطأ المسار والكلمة المفتاحية التي فشلت، مما يسمح بتحديد موقعه بسهولة في محررك.

اختلافات المسودات التي تسبب المشكلات

الكلمة المفتاحية المسودة 04 المسودة 07 المسودة 2020-12
id مقابل $id id $id $id
exclusiveMaximum كقيمة bool نعم رقم رقم
صياغة المصفوفة items items items prefixItems
$ref يسمح بالكلمات المفتاحية المجاورة لا لا نعم

اضبط المسودة الصحيحة؛ فالتحقق من مخطط المسودة 04 على أنه 2020-12 سيؤدي إلى تفسير خاطئ للكلمة id وبعض التفاصيل الدقيقة الأخرى.

سير العمل النموذجي

  • اختبار عقد واجهة برمجة التطبيقات (API): قبل النشر، شغّل مخطط OpenAPI المُولَّد أو المُحدَّث على استجابات نموذجية حقيقية.
  • تعزيز الإعدادات: تحقق من صحة كل ملف إعدادات بصيغة YAML/JSON في مرحلة الـ CI وفقًا لمخطط محدد قبل الدمج.
  • استيعاب البيانات: ارفض مبكرًا الحمولات التي لا تطابق الشكل المتوقع، مع رسالة خطأ واضحة.

الأخطاء الشائعة

  • إغفال فرض format. بشكل افتراضي، تتعامل معظم أدوات التحقق مع الصيغ غير المعروفة كتعليقات توضيحية فقط. فعّل التحقق الصارم من الصيغة لرفض عناوين البريد الإلكتروني والتواريخ غير الصالحة فعليًا.
  • الإفراط في استخدام oneOf. إذا تداخل فرعان من oneOf، فسيفشل المستند (يجب أن يطابق فرعًا واحدًا بالضبط). استخدم anyOf أو أنماط التمييز.
  • المخططات الصارمة مع additionalProperties: false. تصبح إضافة حقل اختياري جديد تغييرًا كاسرًا للتوافق. تجنّب استخدامها ما لم تكن ترغب فعلًا في كائن مغلق.

الأسئلة الشائعة

نعم. المسودات 2020-12 و07 و04 مدعومة جميعًا. تقرأ الأداة الكلمة المفتاحية $schema من مستندك لاختيار النموذج المناسب، أو تعود تلقائيًا إلى أداة الاختيار في واجهة المستخدم.

يتم التحقق من الصيغ القياسية (email، date-time، uuid، ipv4، إلخ) عند تفعيل التحقق الصارم من الصيغة. أما الصيغ المخصصة المُعرَّفة في مخططك فتُعامَل كتعليقات توضيحية فقط، ما لم تُوفّر تعبيرًا نمطيًا (regex) عبر pattern.

تُحلّ المراجع الداخلية (#/$defs/foo) تلقائيًا. ولا تُجلب المراجع الخارجية عبر HTTP بشكل افتراضي، وذلك لأسباب أمنية. ضمّن مراجعك الخارجية مباشرةً أولًا، أو استخدم أداة متخصصة تدعم حل مراجع $ref عن بُعد.

نعم. يبقى كل من المخطط والمستند محليًا. لا يُرفع المحتوى الملصوق أبدًا، مما يجعله آمنًا لعقود واجهات برمجة التطبيقات (API) الداخلية وللبيانات الحساسة.

أدوات ذات صلة

الأداة متاحة بلغات أخرى