👩‍👩‍👦‍👦 🎁 🕔 ما هو XML 👨🏽‍⚕️ 🛠️ 🍿

إذا كنت تختبر API ، فهناك تنسيقان رئيسيان لنقل البيانات يجب أن تعرفهما:

XML - يستخدم في SOAP (دائمًا) وطلبات REST (أقل كثيرًا) ؛
JSON - تُستخدم في طلبات REST.

اليوم سوف أقدم لكم XML.

XML ، المترجمة من الإنجليزية e X tensible M arkup L anguage هي لغة ترميز قابلة للتوسيع. تستخدم لتخزين ونقل البيانات. لذلك يمكنك رؤيته ليس فقط في API ، ولكن أيضًا في الكود.

هذا التنسيق موصى به من قبل اتحاد شبكة الويب العالمية (W3C) ، لذلك غالبًا ما يستخدم لنقل البيانات عبر API. في SOAP API ، هذا هو بشكل عام التنسيق الوحيد الممكن لبيانات الإدخال والإخراج!

راجع أيضًا:

ما

المقصود بواجهة برمجة التطبيقات (API) - مقدمة عامة لمقدمة واجهة برمجة التطبيقات إلى SOAP و REST: ما هي وماذا نأكل - فيديو عن الفرق بين SOAP و REST.

لذلك دعونا نتعرف على شكله ، وكيفية قراءته ، وكيفية كسره! نعم ، نعم ، ولكن أين بدونها؟ بعد كل شيء ، من الضروري معرفة كيفية تفاعل النظام مع تنسيق منحنى البيانات المرسلة.

المحتوى

كيف يعمل XML

لنأخذ مثالاً من وثائق تلميحات الاسم الكامل لـ Dadata :

<req>
<query> </query>
<count>7</count>
</req>

ودعنا نتعرف على معنى هذا الإدخال.

العلامات

في XML ، يجب تغليف كل عنصر بعلامات. العلامة عبارة عن نص ملفوف بين أقواس زاوية:

<tag>

النص الموجود داخل أقواس الزاوية هو اسم العلامة.

هناك دائمًا علامتان:

الفتاحة - نص داخل أقواس زاوية
```
<tag>
```
الخاتمة - نفس النص (هذا مهم!) ، لكن الرمز "/" يضاف
```
</tag>
```

أوه ، حسنًا ، تم القبض عليك! ليس دائما. هناك أيضًا عناصر فارغة ، لديهم علامة واحدة ، يتم فتحها وإغلاقها في نفس الوقت. ولكن أكثر عن ذلك لاحقا!

بمساعدة العلامات ، نعرض النظام "هنا يبدأ العنصر ، وهنا ينتهي". إنها مثل إشارات الطرق:

- عند مدخل المدينة ، يتم كتابة اسمها: موسكو

- عند المخرج ، يتم كتابة نفس الاسم ، ولكن تم شطبها: ~~موسكو~~ *

* مثال على لافتات الطرق التي قرأتها ذات مرة منذ فترة طويلة في مقال في Yandex ، فقط لا أتذكر الرابط. ومثال ممتاز!

عنصر الجذر

يحتوي أي مستند XML على عنصر جذر. هذه هي العلامة التي يبدأ بها المستند وينتهي بها. في حالة واجهة برمجة تطبيقات REST ، يكون المستند عبارة عن طلب يرسله النظام. أو الجواب الذي تحصل عليه.

لتعيين هذا الطلب ، نحتاج إلى عنصر جذر. في تلميحات الأدوات ، العنصر الجذر هو "req".

يمكن تسميته بشكل مختلف:

<main>

<sugg>

نعم أيا كان. إنه يوضح بداية ونهاية طلبنا ، لا أكثر. ولكن يوجد بالداخل بالفعل نص المستند - الطلب نفسه. تلك المعلمات التي نمررها إلى النظام الخارجي. بالطبع ، ستكون أيضًا في العلامات ، ولكن في العلامات العادية ، وليس في العلامات الجذرية.

قيمة البند

يتم تخزين قيمة العنصر بين علامتي البداية والنهاية. يمكن أن يكون رقمًا أو سلسلة أو حتى علامات متداخلة!

هنا لدينا علامة "الاستعلام". يشير إلى الطلب الذي نرسله إلى تلميحات الأدوات.

الداخل - قيمة الطلب.

يبدو الأمر كما لو أننا دفعنا الخط "Victor Ivan" إلى واجهة المستخدم الرسومية (واجهة المستخدم الرسومية):

لا يحتاج المستخدم إلى ربط إضافي ، فهو بحاجة إلى شكل جميل. لكن النظام يجب أن ينقل بطريقة أو بأخرى أن "المستخدم أدخل هذا بالضبط." كيف أريها أين تبدأ القيمة التي تم تمريرها وتنتهي؟ هذا هو الغرض من العلامات.

يرى النظام علامة "الاستعلام" ويفهم أن بداخلها عبارة عن "سلسلة يجب إرجاع المطالبات من أجلها". عدد

المعلمات = 7يشير إلى عدد التلميحات التي سيتم إرجاعها في الاستجابة. إذا قمت بكز النصائح في نموذج Dadata التجريبي ، فستعود إلينا 7 نصائح. هذا لأن عدد القيمة = 7 مخيط فيه . ولكن إذا أشرت إلى توثيق الطريقة ، فيمكن تحديد العدد من 1 إلى 20.

افتح وحدة تحكم المطور عبر f12 ، علامة تبويب الشبكة ، واطلع على الطلب الذي يتم إرساله إلى الخادم. سيكون هناك عدد = 7 .

راجع أيضًا:

ما يحتاج المُختبِر إلى معرفته حول لوحة المطوِّر - تعرف على المزيد حول كيفية استخدام وحدة التحكم.

ملحوظة:

فيكتور إيفان - سلسلة
7 - رقم

لكن كلا القيمتين تأتي بدون اقتباسات. في XML ، لا نحتاج إلى تضمين قيمة السلسلة بين علامتي اقتباس (لكن في JSON ، علينا القيام بذلك).

سمات العنصر

يمكن أن يحتوي العنصر على سمة واحدة أو أكثر. نشير إليها داخل العلامة المقطوعة بعد فصل اسم العلامة بمسافة في النموذج

_ = « »

على سبيل المثال:

<query attr1=“value 1”> </query>
<query attr1=“value 1” attr2=“value 2”> </query>

لماذا هذا مطلوب؟ من السمات ، يفهم النظام الذي يتلقى طلب واجهة برمجة التطبيقات ما استلمه على الإطلاق.

على سبيل المثال ، نجري بحثًا على النظام ، ونبحث عن عملاء باسم Oleg. نرسل طلب بسيط:

<query></query>

وفي المقابل نحصل على حزمة كاملة من Olegs! مع اختلاف تواريخ الميلاد وأرقام الهواتف والبيانات الأخرى. لنفترض أن إحدى نتائج البحث تبدو كالتالي:

<party type="PHYSICAL" sourceSystem="AL" rawId="2">
    <field name=“name"> </field>
    <field name="birthdate">02.01.1980</field>
    <attribute type="PHONE" rawId="AL.2.PH.1">
        <field name="type">MOBILE</field>
        <field name="number">+7 916 1234567</field>
    </attribute>
</party>

دعونا نلقي نظرة على هذا الإدخال. لدينا حزب العنصر الرئيسي .

لها 3 سمات:

type = «PHYSICAL» — . , : , , . , . ! , , — ,
sourceSystem = «AL» — . , , .
rawId = «2» — . , , . , ? sourceSystem + rawId!

هناك عناصر ميدانية داخل الحزب . عناصر الحقل لها اسم سمة . قيمة السمة هي اسم الحقل: الاسم أو تاريخ الميلاد أو النوع أو رقم الهاتف. هذه هي الطريقة التي نفهم بها ما هو مخفي تحت حقل معين . يعد هذا مناسبًا من وجهة نظر الدعم عندما يكون لديك منتج محاصر وأكثر من 10 عملاء. سيكون لكل عميل مجموعة الحقول الخاصة به: شخص ما لديه INN في النظام ، شخص ما ليس كذلك ، واحد مهم بالنسبة لتاريخ الميلاد ، وآخر ليس كذلك ، إلخ. ولكن ، على الرغم من الاختلاف في النماذج ، سيكون لدى جميع العملاء مخطط XSD واحد (يصف الطلب والاستجابة): - يوجد عنصر مجموعة ؛ - يحتوي على عناصر ميدانية ؛

- لكل عنصر حقل سمة اسم تخزن اسم الحقل.

لكن لم يعد من الممكن وصف الأسماء المحددة للحقول في XSD. هم بالفعل "انظروا في المعارف التقليدية". بالطبع ، عندما يكون هناك عميل واحد فقط أو عندما تصنع برنامجًا لنفسك أو "بشكل عام للجميع" ، يكون من الأنسب استخدام الحقول المسماة - أي علامات "التحدث". ما هي مزايا هذا النهج:

- عند قراءة XSD ، تظهر الحقول الحقيقية على الفور. قد تكون المعارف التقليدية قديمة ، وسيكون الرمز محدثًا.

- الطلب سهل السحب يدويًا في SOAP Ui - سيُنشئ على الفور جميع الحقول الضرورية ، ما عليك سوى ملء القيم. هذا مناسب للمختبِر + العميل أحيانًا يختبر مثل هذا ، إنه أيضًا جيد.

بشكل عام ، أي نهج له الحق في الوجود. من الضروري إلقاء نظرة على المشروع الذي سيكون أكثر ملاءمة لك. في المثال الخاص بي ، لدي أسماء عناصر غير ناطقة - كل ذلك كما سيكون واحدًاالمجال . ولكن من خلال السمات ، يمكنك بالفعل فهم ما هو عليه.

بالإضافة إلى عناصر الحقل ، يمتلك الحزب عنصر سمة . لا تخلط بين تدوين xml وقراءة الأعمال:

من وجهة نظر العمل ، هذه سمة من سمات الفرد ، ومن هنا جاء اسم العنصر - السمة .
من وجهة نظر xml هو عنصر (وليس سمة!) ، لقد تم تسميته ببساطة سمة . لا يهتم XML (تقريبًا) بكيفية تسمية العناصر ، لذلك لا بأس بذلك.

و السمة عنصر ديه سمات:

اكتب = "PHONE" - نوع السمة. بعد كل شيء ، يمكن أن تكون مختلفة: الهاتف ، العنوان ، البريد الإلكتروني ...
rawId = "AL.2.PH.1" - المعرف في نظام المصدر. هناك حاجة للتحديث. بعد كل شيء ، يمكن لعميل واحد أن يمتلك عدة هواتف ، كيف يمكن للمرء أن يفهم أي هاتف يتم تحديثه بدون معرف؟

هذا هو XML تحولت. ومبسطة. في الأنظمة الحقيقية التي يتم فيها تخزين الأفراد ، هناك الكثير من البيانات: حوالي 20 حقلاً للفرد نفسه ، وعناوين متعددة ، وأرقام هواتف ، وعناوين بريد إلكتروني ...

ولكن قراءة XML الضخم لن يكون صعبًا إذا كنت تعرف ما هو المكان. وإذا تم تنسيقه ، يتم إزاحة العناصر المتداخلة إلى اليمين ، والباقي في نفس المستوى. سيكون الأمر صعبًا بدون تنسيق ...

وكل شيء بسيط للغاية - لدينا عناصر مضمنة في العلامات. داخل العلامات اسم العنصر. إذا كان هناك شيء ما بعد الاسم ، مفصولاً بمسافة: فهذه هي سمات العنصر.

مقدمة XML

أحيانًا في الجزء العلوي من مستند XML ، سترى شيئًا مشابهًا:

<?xml version="1.0" encoding="UTF-8"?>

يسمى هذا الخط مقدمة XML. يعرض إصدار XML المستخدم في المستند ، بالإضافة إلى الترميز. المقدمة اختيارية ، إذا لم تكن موجودة - فلا بأس. ولكن إذا كان الأمر كذلك ، فيجب أن يكون السطر الأول من مستند XML.

UTF-8 هو الترميز الافتراضي لمستندات XML.

مخطط XSD

XSD ( X ML S chema D efinition) هو وصف XML الخاص بك. كيف يجب أن تبدو ، ماذا يجب أن تكون؟ هذه المعارف التقليدية مكتوبة بلغة الآلة - بعد كل شيء ، نكتب المخطط ... أيضًا بتنسيق XML! والنتيجة هي XML الذي يصف XML آخر.

الحيلة هي أن الفحص وفقًا للمخطط يمكن تفويضه إلى الجهاز. والمطور لا يضطر حتى إلى جدولة كل شيك. يكفي أن تقول "هنا رسم بياني ، تحقق منه."

إذا أنشأنا طريقة SOAP ، فإننا نشير في المخطط:

ما هي الحقول التي ستكون في الطلب ؛
ما هي المجالات التي ستكون في الرد ؛
ما أنواع البيانات التي يحتوي عليها كل حقل ؛
ما هي الحقول المطلوبة والتي ليست كذلك ؛
هل الحقل له قيمة افتراضية وما هي؟
هل الحقل له حد طول؟
هل يحتوي الحقل على معلمات أخرى؟
;
...

الآن ، عندما يأتي إلينا طلب ، يتم التحقق أولاً من صحته وفقًا للمخطط. إذا كان الطلب صحيحًا ، فإننا نطلق الطريقة ونعمل على منطق الأعمال. ويمكن أن تكون معقدة وكثيفة الموارد! على سبيل المثال ، قم بعمل عينة من قاعدة بيانات بملايين الدولارات. أو قم بإجراء عشرات الفحوصات على جداول قاعدة بيانات مختلفة ...

فلماذا إذن ننفذ إجراءً معقدًا إذا كان الاستعلام واضحًا "سيئًا"؟ وتعطي خطأ بعد 5 دقائق وليس على الفور؟ يساعد التحقق من صحة المخطط على التصفية السريعة للطلبات غير الصالحة بشكل واضح دون زيادة التحميل على النظام.

علاوة على ذلك ، تضع بعض برامج العملاء حماية مماثلة لإرسال الطلبات. على سبيل المثال ، يمكن لـ SOAP Ui التحقق من طلبك للحصول على xml جيد التكوين ، ولن يتم إرساله إلى الخادم إذا حدث خطأ. يوفر الوقت في نقل البيانات ، أحسنت!

وبالنسبة للمستخدم البسيط لواجهة SOAP API ، يساعدك المخطط على فهم كيفية إنشاء طلب. ما هو "المستخدم البسيط"؟

مطور النظام باستخدام واجهة برمجة التطبيقات (API) الخاصة بك - يجب أن يكتب في الكود ما يرسله بالضبط من نظامه إلى نظامك.
المختبِر الذي يحتاج إلى التحقق من واجهة برمجة التطبيقات هذه - يحتاج إلى فهم كيفية تشكيل الطلب.

نعم ، نعم ، من الناحية المثالية لدينا معارف تقليدية مفصلة ، حيث يتم وصف كل شيء بشكل جيد. لكن للأسف ، هذا ليس هو الحال دائمًا. في بعض الأحيان ، لا توجد المعارف التقليدية ببساطة ، وفي بعض الأحيان تكون قديمة. لكن المخطط لن يصبح قديمًا ، لأنه يتم تحديثه عند تحديث الكود. ويساعد فقط فهم الشكل الذي يجب أن يبدو عليه الطلب.

باختصار ، كيف يتم استخدام المخطط عند تطوير SOAP API:

يكتب مطورنا مخطط XSD لطلب واجهة برمجة التطبيقات: تحتاج إلى تمرير عنصر كذا وكذا ، والذي سيكون له كذا وكذا ، مع أنواع البيانات هذه وكذا. هذه مطلوبة ، وهذه ليست كذلك.
يقرأ مطور نظام العميل المتكامل مع نظامنا هذا المخطط ويبني طلباته وفقًا له.
يرسل نظام العملاء الطلبات إلينا.
يتحقق نظامنا من طلبات XSD - إذا حدث خطأ ما ، فهذا مجرد اهتزاز.
إذا اجتاز طلب XSD عملية التحقق ، فقم بتشغيل منطق الأعمال!

الآن دعونا نرى كيف يمكن أن تبدو الدائرة! خذ طريقة doRegister في المستخدمين على سبيل المثال . لإرسال طلب ، يجب علينا تمرير البريد الإلكتروني والاسم وكلمة المرور. هناك العديد من الطرق لكتابة استعلام بشكل صحيح وخاطئ:

طلب صحيح طلب غير صالح

طلب صحيح	طلب غير صالح
`<wrap:doRegister> <email>olga@gmail.com</email> <name></name> <password>1</password> </wrap:doRegister>`	`<wrap:doRegister> <email>name@gmail.com</email> <password>1</password> </wrap:doRegister>` لا يوجد حقل مطلوب للاسم
`<wrap:doRegister> <email>maxim@gmail.com</email> <name>(&$%($</name> <password></password> </wrap:doRegister>`	`<wrap:doRegister> <mail>test@gmail.com</mail> <name>Test</name> <password>1</password> </wrap:doRegister>` خطأ مطبعي في اسم العلامة (البريد بدلاً من البريد الإلكتروني)
...	...

<wrap:doRegister>
   <email>olga@gmail.com</email>
   <name></name>
   <password>1</password>
</wrap:doRegister>

<wrap:doRegister>
   <email>name@gmail.com</email>
   <password>1</password>
</wrap:doRegister>

لا يوجد حقل مطلوب للاسم

<wrap:doRegister>
   <email>maxim@gmail.com</email>
   <name>*(&$%*($</name>
   <password></password>
</wrap:doRegister>

<wrap:doRegister>
   <mail>test@gmail.com</mail>
   <name>Test</name>
   <password>1</password>
</wrap:doRegister>

خطأ مطبعي في اسم العلامة (البريد بدلاً من البريد الإلكتروني)

... ...

دعنا نحاول كتابة رسم تخطيطي لها. يجب أن يحتوي الطلب على 3 عناصر ( البريد الإلكتروني ، الاسم ، كلمة المرور ) من النوع "سلسلة" (سلسلة). نحن نكتب:

<xs:element name="doRegister ">
   <xs:complexType>
   <xs:sequence>
     <xs:element name="email" type="xs:string"/>
     <xs:element name="name" type="xs:string"/>
     <xs:element name="password" type="xs:string"/>
   </xs:sequence>
   </xs:complexType>
</xs:element>

وفي WSDl للخدمة ، تمت كتابته بشكل أسهل:

<message name="doRegisterRequest">
   <part name="email" type="xsd:string"/>
   <part name="name" type="xsd:string"/>
   <part name="password" type="xsd:string"/>
</message>

بالطبع ، يمكن أن يكون هناك أكثر من مجرد عناصر مضمنة في المخطط. يمكن أن تكون هذه أرقامًا وتواريخ وقيمًا منطقية وحتى بعض الأنواع الخاصة بها:

<xsd:complexType name="Test">
   <xsd:sequence>
     <xsd:element name="value"   type="xsd:string"/>
     <xsd:element name="include" type="xsd:boolean" minOccurs="0" default="true"/>
     <xsd:element name="count" type="xsd:int" minOccurs="0" length="20"/>
     <xsd:element name="user" type="USER" minOccurs="0"/>
   </xsd:sequence>
</xsd:complexType>

يمكنك أيضًا الرجوع إلى مخطط آخر في مخطط ، مما يسهل كتابة التعليمات البرمجية - يمكنك إعادة استخدام المخططات لمهام مختلفة.

راجع أيضًا:

XSD - XML الذكي - مقالة مفيدة من

لغة تعريف مخطط Habr XSD - توجد جداول ملائمة مع قيم يمكنك استخدام

لغة وصف مخطط XSD (مخطط XML)

مثال على مخطط XML في البرنامج التعليمي

الموقع الرسمي w3.org

الممارسة: كتابة طلبك

حسنًا ، نحن الآن نعرف كيفية "قراءة" طلب طريقة API بتنسيق XML. ولكن كيف ترسمه وفقًا للمعارف التقليدية؟ لنجرب. نحن ننظر في الوثائق. ولهذا السبب أعطي مثالًا من Dadata - إنه توثيق رائع !

ماذا لو أردت إرجاع الأسماء النسائية التي تبدأ بحرف "An" فقط؟ لنأخذ مثالنا الأصلي:

<req>
  <query> </query>
  <count>7</count>
</req>

بادئ ذي بدء ، نقوم بتغيير الطلب نفسه. الآن لم يعد "فيكتور إيفان" ، ولكن "An":

<req>
  <query></query>
  <count>7</count>
</req>

بعد ذلك ، ننظر إلى المعارف التقليدية. كيفية إرجاع النصائح النسائية فقط؟ هناك معلمة خاصة - الجنس . اسم المعلمة هو اسم العلامات. وقد وضعنا الأرضية بالفعل بالداخل. "أنثى" في اللغة الإنجليزية هي أنثى ، في الوثائق أيضًا. إجمالي المستلم:

<req>
  <query></query>
  <count>7</count>
  <gender>FEMALE</gender>
</req>

يمكنك حذف ما لا لزوم له. إذا لم نهتم بعدد التلميحات ، فإننا نتخلص من معلمة العد. بعد كل شيء ، وفقًا للوثائق ، إنه اختياري. استلمت طلبا:

<req>
  <query></query>
  <gender>FEMALE</gender>
</req>

هذا كل شئ! أخذنا مثالًا كأساس ، وغيرنا قيمة واحدة ، وأضفنا معلمة واحدة ، وأزلنا واحدًا. إنها ليست بتلك الصعوبة. خاصة عندما يكون هناك مواصفات مفصلة ومثال)))

جربها بنفسك!

اكتب طلبًا لطريقة MagicSearch في المستخدمين. نريد أن نجد كل إيفانوف بالصدفة الكاملة ، حيث تتوقف المهام العاجلة.

XML منسق بشكل جيد

الأمر متروك للمطور ليقرر أي XML هو الصحيح وأيها غير صحيح. لكن هناك قواعد عامة لا يمكن انتهاكها. يجب أن يتم تشكيل XML بشكل جيد ، أي أن يكون صحيحًا من الناحية التركيبية.

للتحقق من XML لبناء الجملة ، يمكنك استخدام أي مدقق XML (و google). أوصي بموقع w3schools . يوجد المدقق نفسه + وصف للأخطاء النموذجية بأمثلة.

في المدقق النهائي ، يمكنك ببساطة إدخال XML الخاص بك (على سبيل المثال ، طلب للخادم) ومعرفة ما إذا كان كل شيء على ما يرام معه. لكن يمكنك التحقق من ذلك بنفسك. راجع قواعد بناء الجملة ومعرفة ما إذا كان الاستعلام الخاص بك يتبعها.

قواعد XML جيدة التكوين:

هناك عنصر جذر.
كل عنصر له علامة إغلاق.
العلامات حساسة لحالة الأحرف!
يتم احترام التداخل الصحيح للعناصر.
يتم تضمين السمات في علامات الاقتباس.

دعنا نراجع كل قاعدة ونناقش كيف يمكننا تطبيقها في الاختبار. وهذا يعني ، كيفية "كسر" استعلام بشكل صحيح عن طريق التحقق منه مقابل xml جيد التكوين. لماذا هذا مطلوب؟ انظر إلى ردود الفعل من النظام. هل يمكنك أن تفهم من نص الخطأ بالضبط حيث أخطأت؟

راجع أيضًا:

رسائل الخطأ هي وثائق أيضًا ، اختبرها! - لماذا اختبار رسائل الخطأ

1. هناك عنصر جذر

لا يمكنك وضع 2 XML جنبًا إلى جنب مع افتراض أن "النظام سوف يكتشف بمفرده أن هذين الطلبين ، وليس طلبًا واحدًا". لن يفهم. لأنه لا يجب عليك.

وإذا كان لديك العديد من العلامات المتتالية بدون أصل مشترك ، فهذا يعد xml سيئًا ، وليس بشكل جيد. يجب أن يكون هناك دائمًا عنصر جذر:

لا	نعم
`<test> <user></user> <pass>123</pass> </test> <dev> <user></user> <pass>123</pass> </dev>` هناك عنصرا "test" و "dev" ، لكنهما موجودان بجانب بعضهما البعض ، لكن لا يوجد جذر ، يكمن فيه كل شيء. يبدو مثل 2 مستند XML	`<credential> <test> <user></user> <pass>123</pass> </test> <dev> <user></user> <pass>123</pass> </dev> </credential>` وهنا يوجد بالفعل عنصر اعتماد ، وهو الجذر

ماذا سنفعل لاختبار هذه الحالة؟ هذا صحيح ، نقوم بإزالة علامات الجذر من طلبنا!

2. لكل عنصر علامة إغلاق

كل شيء بسيط هنا - إذا تم فتح علامة في مكان ما ، فيجب إغلاقها في مكان ما. تريد كسر؟ قم بإزالة علامة الإغلاق لأي عنصر.

ولكن هنا تجدر الإشارة إلى أنه يمكن أن يكون هناك علامة واحدة. إذا كان العنصر فارغًا ، فيمكننا الحصول على علامة واحدة بإغلاقه في النهاية:

<name/>

هذا هو نفس تمرير قيمة فارغة فيه

<name></name>

وبالمثل ، يمكن للخادم أن يعيد لنا قيمة علامة فارغة. يمكنك محاولة إرسال الحقول الفارغة إلى المستخدمين بطريقة FullUpdateUser . وهذا مقبول في الطلب (لقد أرسلت حقل name1 فارغًا ) ، وفي استجابة SOAP Ui ، فإنه يعرض الحقول الفارغة لنا تمامًا.

المجموع - إذا كانت هناك علامة افتتاحية ، فيجب أن يكون هناك علامة إغلاق. أو ستكون علامة واحدة بشرطة مائلة في النهاية.

للاختبار ، قم بإزالة أي علامة إغلاق في الطلب.

لا	نعم
`<user>`	`<user></user>`
`</user>`	`<user/>`

3. العلامات حساسة لحالة الأحرف

كما كتبوا الافتتاح - نكتب أيضا الختام. مماثل! وليس بالطريقة التي تريدها.

لكن للاختبار ، نقوم بتغيير سجل أحد الأجزاء. سيكون ملف XML هذا غير صالح

لا	نعم
`<Name></name> <NAME></name> <NAME></name>`	`<name></name>`

4. تصحيح تداخل العناصر

يمكن للعناصر أن تتداخل واحدة تلو الأخرى

يمكن أن

يتداخل عنصر واحد في عنصر آخر ولكن لا يمكن أن تتداخل العناصر مع بعضها البعض!

لا	نعم
`<fio> <name></fio> </name>`	`<fio> </fio> <name></name>`
`<fio> <b> <name></name> </fio></b>`	`<fio> <name></name> </fio>`

5. يتم تضمين السمات في علامات الاقتباس

حتى إذا كنت تفكر في السمة كرقم ، فستكون بين علامتي اقتباس:

<query attr1=“123”> </query>
<query attr1=“” attr2=“123” > </query>

لأغراض الاختبار ، نحاول اجتيازه بدون علامات اقتباس:

<query attr1=123> </query>

مجموع

يستخدم XML (e X tensible M arkup L anguage) لتخزين ونقل البيانات.

— API-. SOAP-, . SOAP XML. REST, — XML, JSON.

— XML . , . XML - , , - .

XML open-source folks. , JacksonJsonProvider, «» — , (featuresToEnable), , (featuresToDisable).

تنسيق XML يتبع المعايير. لن يذهب الطلب غير الصحيح من الناحية النحوية إلى الخادم ، وسيقوم العميل بقطعه. تشكيل جيد أولاً ، ثم منطق الأعمال.

قواعد XML جيدة التكوين:

هناك عنصر جذر.
كل عنصر له علامة إغلاق.
العلامات حساسة لحالة الأحرف!
يتم احترام التداخل الصحيح للعناصر.
يتم تضمين السمات في علامات الاقتباس.

إذا كنت مختبِرًا ، فعند اختبار استعلامات XML ، تأكد من محاولة كسر كل قاعدة! نعم ، يجب أن يكون النظام قادرًا على معالجة هذه الأخطاء وإرجاع رسالة خطأ مناسبة. لكنها لا تفعل هذا دائمًا.

وإذا كان النظام عامًا ويعيد استجابة فارغة لطلب غير صحيح ، فهذا أمر سيء. لأن مطور نظام آخر سيصلحه في الطلب ، لكن بالإجابة الفارغة لن يفهم حتى أين بالضبط. وسوف يضايق الدعم: "ما هو الخطأ معي؟" ، رمي المعلومات قطعة قطعة وعلى شكل لقطات من الكود المصدري. هل تحتاجه؟ لا؟ ثم تأكد من أن النظام يعطيك رسالة خطأ واضحة!

راجع أيضًا:

ما هو برنامج XML XML

Tutorial

Learn XML. إريك راي (كتاب XML)

ملاحظات حول XML و XLST

ملاحظة - لمزيد من المقالات المفيدة ، انظر إلى مدونتي تحت علامة "مفيدة" . ومقاطع فيديو مفيدة على قناة اليوتيوب الخاصة بي

ما هو XML