كيفية اختبار واجهة برمجة تطبيقات SOAP عبر الإنترنت: أدوات ومثال عملي

لم يختف SOAP بعد. لا تزال الأنظمة المصرفية وبوابات الدفع والخدمات الحكومية ومنصات المؤسسات القديمة تعرض نقاط نهاية SOAP، ويجب على شخص ما اختبارها. إذا أمضيت حياتك المهنية في REST و JSON، فقد تبدو خدمة SOAP غريبة. البروتوكول أكثر صرامة، وحمولات البيانات هي XML، والعقد موجود في ملف WSDL منفصل.

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

لماذا يختلف اختبار SOAP

REST هو نمط. SOAP هو بروتوكول بقواعد. هذا التمييز يشكل كل شيء حول كيفية اختباره.

رسالة SOAP هي دائمًا مستند XML ملفوف في "مغلف". يحتوي المغلف على رأس للبيانات الوصفية مثل المصادقة أو التوجيه، وجسم يحمل العملية الفعلية ومعاملاتها. لا يمكنك ببساطة إرسال كائن JSON غير مقيد. الهيكل إلزامي، ويتم رفض المغلف المشوه قبل تشغيل منطقك على الإطلاق. يسافر SOAP دائمًا تقريبًا عبر HTTP POST، حتى للعمليات التي تقرأ البيانات فقط، ويتوقع Content-Type محددًا، عادةً text/xml أو application/soap+xml.

أكبر فرق عملي هو WSDL. ملف WSDL، أو لغة وصف خدمات الويب، هو عقد يمكن قراءته آليًا يسرد كل عملية تقدمها الخدمة، والشكل الدقيق لكل طلب واستجابة، وعنوان نقطة النهاية. نادرًا ما يقدم REST أي شيء بهذه الصرامة. عندما تختبر SOAP، فإن WSDL هو خريطتك. يقرأ مختبر SOAP جيد عبر الإنترنت ملف WSDL ويولد قوالب طلبات لك، لذلك لا تقوم بكتابة المغلفات يدويًا من الذاكرة. إذا كنت تريد صورة العقد الأوسع، فإن ملاحظاتنا حول اختبار عقد API تشرح لماذا يعد العقد الصارم ميزة.

كيف يبدو طلب SOAP في الواقع

إليك طلب SOAP واقعي مقابل خدمة تحويل العملات. لاحظ المغلف، وإعلانات مساحة الاسم، والعملية المتداخلة في الجسم.

POST /CurrencyService.asmx HTTP/1.1
Host: rates.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "https://rates.example.com/ConvertAmount"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:cur="https://rates.example.com/">
  <soap:Header>
    <cur:AuthToken>e9f2a1c7-4b8d-4c2a-9f31-7d6e5a4b3c21</cur:AuthToken>
  </soap:Header>
  <soap:Body>
    <cur:ConvertAmount>
      <cur:FromCurrency>USD</cur:FromCurrency>
      <cur:ToCurrency>EUR</cur:ToCurrency>
      <cur:Amount>250.00</cur:Amount>
    </cur:ConvertAmount>
  </soap:Body>
</soap:Envelope>

تأتي الاستجابة ملفوفة بنفس الطريقة:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:cur="https://rates.example.com/">
  <soap:Body>
    <cur:ConvertAmountResponse>
      <cur:ConvertAmountResult>231.45</cur:ConvertAmountResult>
    </cur:ConvertAmountResponse>
  </soap:Body>
</soap:Envelope>

هناك تفصيلان يربكان الناس. مطلوب رأس SOAPAction HTTP بواسطة العديد من الخدمات ويجب أن يتطابق مع العملية، وإلا ستحصل على خطأ. وعندما يفشل شيء ما، لا يُرجع SOAP خطأ HTTP 400 برسالة مرتبة. بل يُرجع HTTP 200 مع عنصر <soap:Fault> داخل الجسم. يجب على اختبارك تحليل الجسم لمعرفة ما إذا كانت المكالمة قد نجحت حقًا. فحص رمز الحالة وحده لا يكفي، وهذا أحد الأسباب التي تجعل تأكيدات API المنظمة أكثر أهمية هنا مما هي عليه في REST.

أدوات عبر الإنترنت لاختبار واجهات برمجة تطبيقات SOAP

أبيدوج (Apidog)

يتعامل Apidog مع SOAP جنبًا إلى جنب مع REST و GraphQL و WebSocket في مكان واحد. يمكنك استيراد WSDL، ويولد بنية الطلب حتى لا تضطر إلى بناء المغلفات يدويًا. يمكنك إضافة تأكيدات على عناصر XML، وتسلسل الطلبات في سيناريو، وتشغيل كل ذلك كمجموعة آلية. ولأنه يصمم ويسخر واجهات برمجة التطبيقات أيضًا، يمكنك محاكاة استجابة SOAP قبل أن تكون الخدمة الحقيقية جاهزة. قم بتنزيل Apidog لاختبار خدمات SOAP على الطبقة المجانية.

سوب يو آي (SoapUI)

SoapUI هي الأداة الأصلية لاختبار SOAP ولا تزال الأعمق. وجهها إلى WSDL وستبني مشروعًا مع كل عملية. الإصدار مفتوح المصدر مجاني وقوي لاختبارات SOAP الوظيفية والمعتمدة على البيانات. إنه تطبيق سطح مكتب Java أثقل، وتوجد ميزات التقارير الأكثر دقة في طبقة ReadyAPI المدفوعة. لإلقاء نظرة فاحصة، انظر ما هو SoapUI وكيف يعمل.

بوستمان (Postman)

يمكن لـ Postman إرسال طلبات SOAP. تقوم بتعيين الجسم إلى XML خام، وإضافة رؤوس Content-Type و SOAPAction يدويًا، ولصق مغلفك. إنه يعمل، لكن Postman لا يحلل WSDL، لذا عليك بناء المغلفات بنفسك. إنه جيد للتحقق لمرة واحدة وأقل راحة لسطح SOAP كبير.

أدوات اختبار SOAP المستندة إلى المتصفح

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

سير عمل سريع لاختبار SOAP

1. احصل على WSDL. تعرض معظم خدمات SOAP ذلك بإضافة ?wsdl إلى عنوان URL لنقطة النهاية. افتحه وتأكد من تحميله.
2. استورد WSDL إلى أداتك. يقوم Apidog و SoapUI بإنشاء قوالب طلبات منه. هذا هو أكبر موفر للوقت.
3. املأ معلمات العملية. استخدم قيمًا حقيقية. اختبر تحويل العملة بمبلغ فعلي ورموز عملات صحيحة.
4. اضبط الرؤوس. تأكد من Content-Type، وعند الحاجة، SOAPAction. يعتبر SOAPAction المفقود السبب الأكثر شيوعًا لخطأ غير مفسر.
5. أرسل وافحص الجسم. لا تتوقف عند حالة HTTP. افتح جسم الاستجابة وتحقق من وجود <soap:Fault>.
6. أضف تأكيدات. أكد أن عنصرًا معينًا موجود ويحمل القيمة المتوقعة. ثم قم بتسلسل مكالمة متابعة إذا كان تدفقك يتطلب ذلك.

لتنظيم هذه في مجموعة قابلة للصيانة، ينطبق دليلنا حول بناء مجموعات اختبار لأتمتة API مباشرة على عمل SOAP.

أخطاء SOAP وكيفية التأكد منها

خطأ SOAP هو هيكل الخطأ الخاص بالبروتوكول. يحمل faultcode و faultstring، وأحيانًا عنصر detail. نظرًا لأنه يصل مع رمز HTTP 200، فإن الاختبار الذي يتحقق من الحالة فقط سينجح في مكالمة فاشلة. وهذا خطأ إيجابي صامت وخطير.

اكتب تأكيدات SOAP الخاصة بك للبحث داخل الجسم. أكد أنه لا يوجد عنصر <soap:Fault> موجود في مسار النجاح. في مسار خطأ متعمد، أكد العكس، وأن الخطأ يظهر وأن faultcode يطابق ما تتوقعه. اختبار حالات الفشل لا يقل أهمية عن المسار السعيد، لأن خدمات SOAP غالبًا ما تشفر قواعد العمل، مثل معاملة مرفوضة، كأخطاء بدلاً من بيانات. يصف توثيق W3C SOAP fault الهيكل إذا كنت بحاجة إلى التفاصيل الرسمية.

تضيف WS-Security طبقة أخرى. تتوقع العديد من خدمات SOAP المؤسسية رأس أمان موقّع أو يحمل رمزًا. إذا فشلت طلباتك بسبب خطأ في المصادقة، فإن WSDL أو وثائق الخدمة ستوضح ملف تعريف الأمان المستخدم. تتيح لك أدوات مثل SoapUI و Apidog تكوين هذه الرؤوس بدلاً من كتابة XML يدويًا.

قراءة WSDL دون الضياع

يبدو ملف WSDL مخيفًا في المرة الأولى التي تفتحه فيها. إنه XML طويل ومتداخل بعمق، ومعظمه عبارة عن تجهيزات آلية. لا تحتاج إلى قراءة كل شيء منه. تحمل أربعة أجزاء المعلومات التي تريدها بالفعل.

يحدد قسم types هياكل البيانات، وعادة ما يكون ذلك كـ XML Schema، لذا هذا هو المكان الذي تتعرف فيه على الشكل الدقيق والقيود لكل معلمة. تصف عناصر message المدخلات والمخرجات لكل عملية. يسرد portType العمليات نفسها، وهي الاستدعاءات التي يمكنك إجراؤها. توفر أقسام service و binding عنوان نقطة النهاية المحدد وتفاصيل النقل. عندما تستورد WSDL إلى أداة، فإنها تقرأ الأربعة وتحولها إلى طلبات جاهزة للتعديل، وهذا هو السبب في أن الاستيراد أفضل من الكتابة اليدوية في كل مرة.

تفصيل واحد يستحق المعرفة: يمكن لملف WSDL أن ينقسم إلى ملفات متعددة باستخدام عبارات import، وغالبًا ما يسحب المخططات من مواقع منفصلة. إذا أبلغت أداتك عن نوع مفقود، فمن المحتمل أن يكون ملفًا مشار إليه قد فشل في الحل. تأكد من أن كل عنوان URL مستورد يمكن الوصول إليه من حيث تعمل أداتك. هذا النوع من تبعية العقود هو بالضبط السبب في أن الفرق تتعامل مع WSDL كـ "مصدر بيانات" (artifact) ذي إصدار بدلاً من شيء يعيش فقط على خادم.

اختبار SOAP مدفوع بالبيانات

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

الاختبار المدفوع بالبيانات يحل هذه المشكلة. تكتب الطلب مرة واحدة مع عناصر نائبة، ثم تغذيه بجدول من صفوف الإدخال والنتائج المتوقعة. تقوم الأداة بتشغيل الطلب لكل صف وتتحقق من كل نتيجة. دعم SoapUI هذا النمط لسنوات، ويدعمه Apidog من خلال مشغل السيناريو الخاص به. العائد هو تغطية حقيقية للحالات الهامشية التي تميل خدمات SOAP إلى تشفيرها كأخطاء. للنمط الأوسع، يشرح دليلنا حول اختبار API المدفوع بالبيانات باستخدام CSV و JSON كيفية هيكلة بيانات الإدخال، وينطبق على SOAP تمامًا كما ينطبق على REST.

الأسئلة المتكررة

ما الفرق بين اختبار SOAP و REST؟

يعمل اختبار SOAP مقابل بروتوكول XML صارم مع عقد WSDL، ومغلفات إلزامية، وأخطاء يتم إرجاعها داخل جسم HTTP 200. يتعامل اختبار REST عادةً مع JSON، واتفاقيات أكثر مرونة، ورموز حالة HTTP ذات معنى. يجب على اختبار SOAP تحليل جسم الاستجابة للتأكد من النجاح؛ بينما يمكن لاختبار REST غالبًا الوثوق برمز الحالة.

هل أحتاج إلى WSDL لاختبار SOAP API؟

يمكنك إرسال طلب SOAP بدونه إذا كنت تعرف بالفعل البنية الدقيقة للمغلف. لكن WSDL يجعل الاختبار أسهل بكثير لأن الأدوات تولد قوالب طلبات صحيحة منه. تكشف معظم الخدمات عن WSDL بإضافة ?wsdl إلى عنوان URL لنقطة النهاية. ابدأ دائمًا من هناك.

لماذا يعيد طلب SOAP الخاص بي خطأ على الرغم من أن الحالة هي 200؟

يبلغ SOAP عن الأخطاء كعنصر <soap:Fault> داخل الجسم، وليس كرمز خطأ HTTP، لذا فإن 200 مع خطأ أمر طبيعي. الأسباب المعتادة هي رأس SOAPAction مفقود أو خاطئ، أو مغلف مشوه، أو عدم تطابق في مساحة الاسم، أو فشل في التحقق الأمني. اقرأ faultstring للسبب المحدد.

هل يمكنني اختبار SOAP APIs عبر الإنترنت مجانًا؟

نعم. يدعم Apidog SOAP على طبقته المجانية ويستورد ملفات WSDL، وقد تم بناء الإصدار مفتوح المصدر من SoapUI لـ SOAP. توجد أيضًا أدوات اختبار متصفح خفيفة الوزن للتحققات السريعة، على الرغم من أنها تفتقر إلى دعم التأكيد والأتمتة الحقيقيين.

كيف أقوم بأتمتة اختبارات SOAP API؟

استورد WSDL، ثم قم ببناء سيناريو يسلسل العمليات بالترتيب، وأضف تأكيدات على عناصر الاستجابة وعلى عدم وجود أخطاء، ثم قم بتشغيله من مشغل الأداة أو في مسار CI الخاص بك. يدعم كل من SoapUI و Apidog مجموعات SOAP المجدولة والتي يتم تشغيلها بواسطة المسارات، لذا فإن تشغيل SOAP التراجعي يتناسب مع نفس تدفق الأتمتة مثل REST.