DEV Community

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

Posted on • Originally published at apidog.com

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

لم يختفِ SOAP بعد. ما زالت الأنظمة المصرفية، بوابات الدفع، الخدمات الحكومية، ومنصات المؤسسات القديمة تعرض نقاط نهاية SOAP، ويجب اختبارها بشكل صحيح. إذا كنت معتادًا على REST وJSON، فتعامل مع SOAP كعقد XML صارم: ملف WSDL يصف العمليات، والطلب يُرسل داخل Envelope، والأخطاء قد تظهر داخل جسم الاستجابة حتى لو كانت حالة HTTP هي 200.

جرّب Apidog اليوم

في هذا الدليل ستتعلم كيف تختبر SOAP API عمليًا: كيف تقرأ WSDL، تبني طلب SOAP صحيحًا، تضبط الرؤوس، تكتب تأكيدات على XML، وتتعامل مع soap:Fault.

لماذا يختلف اختبار SOAP عن REST

REST نمط تصميم. SOAP بروتوكول بقواعد واضحة.

في SOAP، الطلب ليس JSON حرًّا. يجب أن يكون مستند XML داخل:

  • Envelope: الغلاف الرئيسي.
  • Header: بيانات وصفية مثل المصادقة أو التوجيه.
  • Body: العملية الفعلية ومعاملاتها.

غالبًا ما يُرسل SOAP عبر HTTP POST، حتى للعمليات التي تقرأ بيانات فقط. ويجب ضبط رؤوس مثل:

Content-Type: text/xml; charset=utf-8
SOAPAction: "https://example.com/SomeOperation"
Enter fullscreen mode Exit fullscreen mode

الفرق الأكبر هو WSDL. ملف WSDL هو العقد الذي يصف:

  • العمليات المتاحة.
  • شكل كل طلب واستجابة.
  • أنواع البيانات.
  • عنوان endpoint.
  • طريقة الربط والبروتوكول.

لذلك عند اختبار SOAP، ابدأ دائمًا من WSDL. أداة جيدة لاختبار SOAP ستقرأ WSDL وتولّد قوالب الطلبات تلقائيًا بدل كتابة XML يدويًا. إذا أردت فهم فكرة العقود بشكل أوسع، راجع اختبار عقد API.

مثال عملي على طلب SOAP

هذا مثال لطلب SOAP لخدمة تحويل عملات. لاحظ وجود Envelope، ومساحات الأسماء، وSOAPAction.

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>
Enter fullscreen mode Exit fullscreen mode

والاستجابة تأتي عادةً داخل 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>
Enter fullscreen mode Exit fullscreen mode

عند الاختبار، لا تكتفِ بفحص HTTP status. في SOAP قد تحصل على 200 OK بينما العملية فشلت فعليًا بسبب وجود:

<soap:Fault>
  ...
</soap:Fault>
Enter fullscreen mode Exit fullscreen mode

لذلك تحتاج إلى تأكيدات على جسم XML نفسه، وليس على رمز الحالة فقط. راجع أيضًا تأكيدات API.

أدوات لاختبار SOAP API عبر الإنترنت

Apidog

يدعم Apidog اختبار SOAP بجانب REST وGraphQL وWebSocket. يمكنك:

  • استيراد WSDL.
  • توليد قوالب SOAP تلقائيًا.
  • تعديل معاملات XML.
  • إضافة تأكيدات على عناصر الاستجابة.
  • تسلسل الطلبات داخل سيناريو.
  • تشغيل الاختبارات كمجموعة آلية.
  • محاكاة استجابات SOAP قبل جاهزية الخدمة الحقيقية.

يمكنك تنزيل Apidog واختبار خدمات SOAP على الطبقة المجانية.

SoapUI

SoapUI من أقدم وأقوى أدوات SOAP. أعطه رابط WSDL وسيبني مشروعًا يحتوي على العمليات المتاحة.

مناسب عندما تحتاج إلى:

  • اختبار SOAP وظيفيًا.
  • تشغيل اختبارات معتمدة على البيانات.
  • التعامل مع مشاريع SOAP كبيرة.
  • إعدادات WS-Security متقدمة.

الإصدار مفتوح المصدر قوي، لكن بعض مزايا التقارير المتقدمة موجودة في ReadyAPI المدفوع. للمزيد، راجع ما هو SoapUI وكيف يعمل.

Postman

يمكن لـ Postman إرسال SOAP، لكنه لا يقرأ WSDL تلقائيًا.

الخطوات تكون يدويًا:

  1. اختر POST.
  2. ضع endpoint.
  3. اجعل body من نوع raw XML.
  4. أضف Content-Type.
  5. أضف SOAPAction إذا كانت الخدمة تتطلبه.
  6. الصق SOAP Envelope يدويًا.

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

أدوات SOAP من المتصفح

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

قيودها الشائعة:

  • دعم ضعيف للتأكيدات.
  • لا توجد أتمتة حقيقية.
  • صعوبة تنظيم test suite.
  • دعم محدود للمصادقة وWS-Security.

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

اتبع هذا التسلسل عند اختبار أي SOAP API.

1. احصل على WSDL

غالبًا يمكنك الوصول إليه بإضافة:

?wsdl
Enter fullscreen mode Exit fullscreen mode

إلى endpoint.

مثال:

https://example.com/PaymentService?wsdl
Enter fullscreen mode Exit fullscreen mode

افتحه في المتصفح وتأكد أنه يُحمّل بدون أخطاء.

2. استورد WSDL في الأداة

في Apidog أو SoapUI، استورد WSDL بدل بناء الطلبات يدويًا.

هذا يعطيك:

  • قائمة العمليات.
  • قوالب الطلبات.
  • أنواع البيانات.
  • namespaces الصحيحة.
  • endpoint الافتراضي.

3. اختر العملية واملأ المعاملات

مثلاً لاختبار تحويل عملات:

<cur:FromCurrency>USD</cur:FromCurrency>
<cur:ToCurrency>EUR</cur:ToCurrency>
<cur:Amount>250.00</cur:Amount>
Enter fullscreen mode Exit fullscreen mode

استخدم قيمًا واقعية، ثم أضف حالات طرفية لاحقًا مثل:

  • مبلغ صفر.
  • مبلغ سالب.
  • عملة غير مدعومة.
  • قيمة مفقودة.
  • قيمة بنوع خاطئ.

4. اضبط الرؤوس

تحقق من:

Content-Type: text/xml; charset=utf-8
SOAPAction: "https://rates.example.com/ConvertAmount"
Enter fullscreen mode Exit fullscreen mode

أكثر سبب شائع لأخطاء SOAP غير واضحة هو SOAPAction مفقود أو غير مطابق للعملية.

في SOAP 1.2 قد يكون النوع:

Content-Type: application/soap+xml; charset=utf-8
Enter fullscreen mode Exit fullscreen mode

لذلك راجع WSDL أو توثيق الخدمة.

5. أرسل الطلب وافحص XML

لا تعتمد على:

HTTP/1.1 200 OK
Enter fullscreen mode Exit fullscreen mode

افتح body وتحقق من:

  • وجود عنصر النتيجة الصحيح.
  • عدم وجود soap:Fault.
  • صحة namespace.
  • صحة القيم المرجعة.

6. أضف تأكيدات

أمثلة على تأكيدات مفيدة:

  • لا يوجد soap:Fault.
  • ConvertAmountResult موجود.
  • القيمة رقمية.
  • القيمة تساوي المتوقع أو ضمن نطاق مقبول.
  • faultcode يطابق الخطأ المتوقع في اختبارات الفشل.

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

التعامل مع أخطاء SOAP

خطأ SOAP يظهر عادةً بهذا الشكل:

<soap:Fault>
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid currency code</faultstring>
  <detail>
    <errorCode>UNSUPPORTED_CURRENCY</errorCode>
  </detail>
</soap:Fault>
Enter fullscreen mode Exit fullscreen mode

المشكلة أن هذا قد يأتي مع:

HTTP/1.1 200 OK
Enter fullscreen mode Exit fullscreen mode

لذلك الاختبار التالي غير كافٍ:

Assert status code == 200
Enter fullscreen mode Exit fullscreen mode

الأفضل أن تضيف تأكيدًا مثل:

Assert response body does not contain <soap:Fault>
Enter fullscreen mode Exit fullscreen mode

وفي اختبار خطأ متوقع:

Assert response body contains <soap:Fault>
Assert faultcode == soap:Client
Assert faultstring contains "Invalid currency"
Enter fullscreen mode Exit fullscreen mode

أسباب أخطاء SOAP الشائعة:

  • SOAPAction مفقود أو خاطئ.
  • XML غير صالح.
  • namespace غير مطابق.
  • عنصر مطلوب غير موجود.
  • نوع بيانات غير صحيح.
  • فشل المصادقة.
  • رأس WS-Security غير صحيح.
  • WSDL قديم مقارنة بالخدمة.

للتفاصيل الرسمية حول بنية SOAP Fault، راجع توثيق W3C SOAP fault.

WS-Security في اختبارات SOAP

بعض خدمات SOAP المؤسسية لا تقبل token بسيطًا داخل header. قد تحتاج إلى WS-Security، مثل:

  • UsernameToken.
  • Timestamp.
  • توقيع رقمي.
  • شهادة.
  • تشفير أجزاء من الرسالة.

مثال مبسط لرأس أمان:

<soap:Header>
  <wsse:Security>
    <wsse:UsernameToken>
      <wsse:Username>api-user</wsse:Username>
      <wsse:Password>secret</wsse:Password>
    </wsse:UsernameToken>
  </wsse:Security>
</soap:Header>
Enter fullscreen mode Exit fullscreen mode

إذا فشل الطلب بسبب المصادقة:

  1. اقرأ faultstring.
  2. راجع WSDL ووثائق الخدمة.
  3. تحقق من نوع WS-Security المطلوب.
  4. لا تكتب الرأس يدويًا إن كانت الأداة تدعم تكوينه.
  5. تأكد من الوقت والتوقيع والشهادة إن كانت الخدمة تتحقق منها.

كيف تقرأ WSDL بسرعة

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

types

يحتوي على تعريفات XML Schema للبيانات.

ابحث هنا عن:

  • أسماء الحقول.
  • الأنواع مثل string وdecimal.
  • الحقول المطلوبة.
  • القيود مثل الطول أو النمط.

message

يحدد رسائل الإدخال والإخراج لكل عملية.

استخدمه لمعرفة:

  • شكل الطلب.
  • شكل الاستجابة.
  • العناصر المرتبطة بكل operation.

portType

يعرض العمليات المتاحة.

مثال:

<operation name="ConvertAmount">
  ...
</operation>
Enter fullscreen mode Exit fullscreen mode

هذا يخبرك بما يمكنك استدعاؤه.

binding وservice

يحددان:

  • البروتوكول.
  • SOAP version.
  • endpoint.
  • تفاصيل النقل.
  • أحيانًا SOAPAction.

إذا استوردت WSDL في أداة، ستقرأ هذه الأقسام وتحوّلها إلى طلبات جاهزة للتعديل.

ماذا تفعل إذا فشل استيراد WSDL؟

قد يفشل الاستيراد لأن WSDL يعتمد على ملفات أخرى عبر import أو include.

تحقق من التالي:

  • كل روابط XSD المستوردة تعمل.
  • الأداة تستطيع الوصول إلى الروابط من شبكتك.
  • لا توجد ملفات خلف VPN أو firewall.
  • لا توجد شهادات TLS مرفوضة.
  • لا توجد redirects تكسر التحميل.
  • نسخة WSDL مطابقة للبيئة التي تختبرها.

إذا كانت الخدمة داخلية، قد تحتاج إلى تشغيل الأداة داخل نفس الشبكة أو توفير نسخة محلية من WSDL وملفات XSD التابعة.

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

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

مثال لخدمة تحويل عملات:

From To Amount Expected
USD EUR 250.00 Success
USD XXX 250.00 Fault
USD EUR 0 Fault أو نتيجة محددة حسب القاعدة
USD EUR -10 Fault

الفكرة:

  1. اكتب SOAP request مرة واحدة.
  2. استخدم placeholders للقيم.
  3. مرّر البيانات من CSV أو JSON.
  4. شغّل الطلب لكل صف.
  5. تحقق من النتيجة المتوقعة.

مثال على قالب:

<cur:ConvertAmount>
  <cur:FromCurrency>{{fromCurrency}}</cur:FromCurrency>
  <cur:ToCurrency>{{toCurrency}}</cur:ToCurrency>
  <cur:Amount>{{amount}}</cur:Amount>
</cur:ConvertAmount>
Enter fullscreen mode Exit fullscreen mode

هذا يقلل التكرار ويزيد تغطية الحالات الطرفية. يشرح دليل اختبار API المدفوع بالبيانات باستخدام CSV وJSON النمط نفسه، وينطبق على SOAP كما ينطبق على REST.

قائمة تحقق سريعة قبل اعتبار اختبار SOAP ناجحًا

استخدم هذه القائمة:

  • [ ] تم تحميل WSDL بنجاح.
  • [ ] تم استيراد العمليات في الأداة.
  • [ ] endpoint صحيح للبيئة المطلوبة.
  • [ ] Content-Type صحيح.
  • [ ] SOAPAction صحيح عند الحاجة.
  • [ ] namespaces مطابقة لـ WSDL.
  • [ ] عناصر الطلب المطلوبة موجودة.
  • [ ] المصادقة أو WS-Security مضبوطة.
  • [ ] لا يوجد soap:Fault في مسار النجاح.
  • [ ] تم اختبار مسارات الفشل المتوقعة.
  • [ ] توجد تأكيدات على XML وليس على status code فقط.
  • [ ] توجد بيانات اختبار للحالات الطرفية.
  • [ ] يمكن تشغيل المجموعة يدويًا أو من CI.

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

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

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

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

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

لماذا أرى خطأ SOAP رغم أن HTTP status هو 200؟

لأن SOAP قد يضع الخطأ داخل:

<soap:Fault>
Enter fullscreen mode Exit fullscreen mode

حتى مع 200 OK. افحص faultstring وfaultcode. الأسباب الشائعة: SOAPAction خاطئ، XML غير صالح، namespace غير مطابق، أو فشل المصادقة.

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

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

كيف أؤتمت اختبارات SOAP API؟

استورد WSDL، أنشئ سيناريوهات للعمليات، أضف تأكيدات على عناصر XML وعلى غياب soap:Fault، ثم شغّل المجموعة من الأداة أو داخل CI. يمكن التعامل مع اختبارات SOAP التراجعية بنفس طريقة REST إذا كانت الأداة تدعم test suites والتشغيل الآلي.

Top comments (0)