XML और SOAP

Q: क्या मैं SOAP service को REST tool से टेस्ट कर सकता हूँ?

हाँ। SOAP request XML body वाली एक HTTP POST है, इसलिए custom headers के साथ raw body भेजने वाला कोई भी tool काम करता है। Content-Type और SOAP 1.1 में SOAPAction आपको ख़ुद set करने होंगे। Dedicated SOAP tools, WSDL से requests बनाने जैसी सुविधाएँ जोड़ते हैं।

Q: कैसे पता करें कि service SOAP 1.1 इस्तेमाल करती है या 1.2?

WSDL की binding देखें: SOAP 1.1 binding namespace http://schemas.xmlsoap.org/wsdl/soap/ इस्तेमाल करती है और SOAP 1.2 binding http://schemas.xmlsoap.org/wsdl/soap12/। कोई service दोनों दे सकती है, हर एक के लिए अलग port के साथ। किसी चलती request में envelope namespace और Content-Type (text/xml या application/soap+xml) भी यही बताते हैं।

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 18 मिनट · मध्यम

XML (Extensible Markup Language), जिसे W3C की XML 1.0 Recommendation परिभाषित करती है, एक text format है जो data को नाम वाले, nested elements में रखता है, जैसे <orderId>ORD-1042</orderId>। SOAP इसी पर बना एक messaging protocol है: हर request और response एक XML document होता है जिसे envelope कहते हैं, और एक WSDL file service के operations और हर operation द्वारा स्वीकार किया जाने वाला ठीक-ठीक XML बताती है।

उदाहरण: किसी order का status जानने के लिए client एक envelope POST करता है जिसकी body में GetOrderStatus और order ID होते हैं, और उसे status वाला envelope या एक SOAP fault मिलता है जो बताता है कि क्या गलत हुआ। REST के उलट, operation का नाम message के अंदर होता है, method और URI से नहीं।

यह क्यों ज़रूरी है

SOAP organisations के बीच integrations में और लंबे समय से चल रहे enterprise systems में आम है, जैसे banking, payment, insurance, government और telecom interfaces, और अक्सर किसी आधुनिक front end के पीछे चलता है। वहाँ एक defect पूरी business process रोक सकता है, जैसे किसी payment का confirm होना।

XML और SOAP, REST पर JSON से अलग तरह से fail होते हैं। एक unescaped & पूरा message अपठनीय बना देता है, गलत namespace वाला element अनजान होता है भले उसका नाम सही दिखे, और SOAP 1.1 गलत input पर भी HTTP 500 लौटाता है। सिर्फ़ status codes पढ़ने वाला defects छोड़ देता है और झूठे defects गढ़ लेता है।

XML basics: well-formed, valid और namespaces

Element एक start tag, उसका content और एक end tag होता है, जैसे <total>249.90</total>; बिना content वाला element <item/> की तरह लिखा जा सकता है। Attribute, start tag के अंदर एक name="value" जोड़ी है, जैसे नीचे दिए document में currency="SAR"। XML document में ठीक एक root element होता है; हर element बंद और सही तरह nested होता है, और names case-sensitive हैं, इसलिए <orderId> और <OrderId> अलग elements हैं। Attribute values quotes में होती हैं, एक element में हर attribute का नाम एक ही बार आता है, और attributes के क्रम का कोई अर्थ नहीं।

इन rules का पालन document को well-formed बनाता है; XML 1.0 हर उल्लंघन को fatal error मानता है, इसलिए parser पूरा message reject करता है, उसे वैसे ठीक नहीं करता जैसे browsers HTML को करते हैं। Valid document किसी schema से भी मेल खाता है (XML 1.0 इसे DTD के लिए परिभाषित करता है); web services required elements, उनका क्रम, types और allowed values तय करने के लिए XML Schema (XSD) इस्तेमाल करती हैं।

Escaping: text में < और & सीधे नहीं आ सकते; < और & लिखें (XML >, " और ' भी पहले से परिभाषित करता है)। CDATA section, <![CDATA[...]]>, text को escape किए बिना ले जाता है।
Encoding: optional declaration <?xml version="1.0" encoding="UTF-8"?> इसे बताता है; उससे मेल न खाने वाले bytes Arabic या Hindi नाम बिगाड़ देते हैं या message reject करवा देते हैं।
Namespaces: xmlns:ord="urn:example:orders" एक prefix को URI से जोड़ता है। Element की पहचान URI और local name से होती है, इसलिए prefix मायने नहीं रखता, और गलत namespace में सही नाम वाला element अनजान है।

<?xml version="1.0" encoding="UTF-8"?>
<order id="ORD-1042" currency="SAR">
  <customer>Smith &amp; Sons</customer>
  <item sku="A-100" qty="2"/>
  <note><![CDATA[Leave at <b>reception</b>]]></note>
  <total>249.90</total>
</order>

आज़माएँ: XML वैलिडेटर आज़माएँ: XML फ़ॉर्मेटर

SOAP envelope और उसकी HTTP binding

SOAP message एक XML document है जिसका root Envelope है। Optional Header request ID या security token जैसा metadata रखता है; ज़रूरी Body request या response element, या एक fault रखती है। mustUnderstand से चिह्नित जिस header block को receiver process न कर सके, उस पर MustUnderstand fault मिलना चाहिए।

Requests आम तौर पर POST से एक ही endpoint URL पर जाती हैं जिसे सारे operations share करते हैं। दोनों SOAP versions envelope namespace और HTTP binding में अलग हैं, इसलिए एक version के लिए बनी request उस service पर fail होती है जो सिर्फ़ दूसरा version support करती है।

SOAP 1.1 request की दो परतें: HTTP headers media type और SOAPAction रखते हैं, और XML envelope का namespace version तय करता है, साथ में optional Header और operation का नाम बताने वाली ज़रूरी Body।

HTTP request line और headers

भाग 1:1POST /services/orders HTTP/1.1
Host: api.example.com
भाग 2:2Content-Type: text/xml; charset=utf-8
भाग 3:3SOAPAction: "urn:example:orders/GetOrderStatus"

XML body: SOAP envelope

भाग 4:4<?xml version="1.0" encoding="UTF-8"?>
भाग 5:5<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               भाग 6:6xmlns:ord="urn:example:orders">
  भाग 7:7<soap:Header>
    <ord:RequestId>7f3c-0091</ord:RequestId>
  </soap:Header>
  भाग 8:8<soap:Body>
    भाग 9:9<ord:GetOrderStatus>
      भाग 10:10<ord:orderId>ORD-1042</ord:orderId>
    </ord:GetOrderStatus>
  </soap:Body>
</soap:Envelope>

1आम तौर पर एक endpoint पर POSTहर operation यही URL इस्तेमाल करता है; operation का नाम Body का element बताता है
2SOAP 1.1 का media typeSOAP 1.2 application/soap+xml इस्तेमाल करता है
3SOAPAction header, सिर्फ़ SOAP 1.1 मेंClient को इसे WSDL binding वाली value के साथ भेजना ही होता है; SOAP 1.2 इसकी जगह action parameter इस्तेमाल करता है
4XML declarationOptional; character encoding बताता है
5SOAP namespace में EnvelopeNamespace version तय करता है; unsupported namespace पर VersionMismatch मिलता है
6Service namespaceSchema का targetNamespace; operation के elements इसी में होने चाहिए
7Header, optionalMessage का metadata, जैसे request ID; mustUnderstand वाला block process होना चाहिए, वरना fault मिलता है
8Body, ज़रूरीRequest या response element, या Fault
9Operation elementइसका नाम और namespace operation चुनते हैं
10XSD के against जाँचा जाने वाला parameterज़रूरी; ORD- के बाद 1 से 8 digits होने चाहिए

SOAP 1.1 (W3C Note, 2000): namespace http://schemas.xmlsoap.org/soap/envelope/, Content-Type: text/xml, और ज़रूरी SOAPAction header, जिसकी value WSDL हर operation के लिए देता है।
SOAP 1.2 (2003 से W3C Recommendation): namespace http://www.w3.org/2003/05/soap-envelope, Content-Type: application/soap+xml, और action, अगर हो, तो उसी header के action parameter में।

पाठ संस्करण

POST /services/orders HTTP/1.1
Host: api.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:example:orders/GetOrderStatus"

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:ord="urn:example:orders">
  <soap:Header>
    <ord:RequestId>7f3c-0091</ord:RequestId>
  </soap:Header>
  <soap:Body>
    <ord:GetOrderStatus>
      <ord:orderId>ORD-1042</ord:orderId>
    </ord:GetOrderStatus>
  </soap:Body>
</soap:Envelope>

आज़माएँ: SOAP रिक्वेस्ट टेस्टर

WSDL: SOAP service का contract

WSDL (Web Services Description Language) document किसी SOAP service का machine-readable contract है, जिसे convention के तौर पर अक्सर endpoint के आगे ?wsdl जोड़कर publish किया जाता है। WSDL 1.1 (2001 का W3C Note) अब भी व्यापक रूप से इस्तेमाल होता है; WSDL 2.0 (2007) portType का नाम interface और port का नाम endpoint कर देता है। WSDL 1.1 के पाँच top-level elements नीचे दिए हैं।

types के अंदर का XSD आपके test basis का सबसे सटीक हिस्सा है। इस section के आख़िर वाले schema में orderId required है (minOccurs की default value 1 है) और उसे ORD- के बाद 1 से 8 digits से match करना होगा, क्योंकि XSD patterns पूरी value से match होते हैं। includeItems optional है और सिर्फ़ true, false, 1 या 0 स्वीकार करता है; xs:sequence क्रम तय करता है; और targetNamespace वह namespace है जिसमें request के elements होने चाहिए।

types: request, response और fault elements की XML Schema definitions।
message: हर operation जो data भेजता या पाता है।
portType: operations, उनके input, output और declared faults के साथ।
binding: SOAP version, document या rpc style, और हर operation का soapAction।
service: port का address, यानी वह URL जिस पर आप requests भेजते हैं।

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="urn:example:orders"
           elementFormDefault="qualified">
  <xs:element name="GetOrderStatus">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="orderId">
          <xs:simpleType>
            <xs:restriction base="xs:string">
              <xs:pattern value="ORD-[0-9]{1,8}"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:element>
        <xs:element name="includeItems" type="xs:boolean" minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

SOAP faults: तय structure वाली errors

जो request process नहीं हो पाती, उसे Body के अंदर एक Fault element मिलता है। SOAP 1.1 में इसमें faultcode, faultstring, optional faultactor और एक detail element होता है, जो तब ज़रूरी है जब Body का content process न हो सका हो; इसमें application-specific data आता है, जैसे WSDL में declared business faults। SOAP 1.2 इन्हें Code (एक Value और optional Subcode के साथ), Reason, Node, Role और Detail कहता है, जिनमें से सिर्फ़ Code और Reason ज़रूरी हैं। सबसे पहले fault code assert करें:

1.1 में Client या 1.2 में Sender: message गलत है — malformed, invalid या गलत value वाला — और बिना बदले दोबारा भेजने पर फिर fail होगा।
1.1 में Server या 1.2 में Receiver: message ठीक था पर processing fail हुई, जैसे database बंद था। यह बाद में सफल हो सकता है।
VersionMismatch: unsupported envelope namespace। MustUnderstand: कोई ज़रूरी header block समझा नहीं गया। SOAP 1.2 DataEncodingUnknown भी जोड़ता है।
HTTP status: SOAP 1.1 हर fault के लिए 500 माँगता है, Client faults के लिए भी; SOAP 1.2 Sender faults पर 400 और बाक़ी पर 500 इस्तेमाल करता है। इसलिए SOAP 1.1 में गलत input के बाद 500 सही है; फ़ैसला fault code करता है।

HTTP/1.1 500 Internal Server Error
Content-Type: text/xml; charset=utf-8

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <soap:Fault>
      <faultcode>soap:Client</faultcode>
      <faultstring>orderId must match ORD- followed by 1 to 8 digits</faultstring>
      <detail>
        <ord:ValidationError xmlns:ord="urn:example:orders">
          <ord:field>orderId</ord:field>
          <ord:value>1042</ord:value>
        </ord:ValidationError>
      </detail>
    </soap:Fault>
  </soap:Body>
</soap:Envelope>

Worked example: GetOrderStatus की टेस्टिंग

Order service टीम के अपने test environment पर SOAP 1.1 से चलती है। Tester WSDL और उसके schema से checks निकालता है, हर एक का expected result लिखकर, और हाथ से लिखे हर envelope को भेजने से पहले well-formedness के लिए जाँचता है (XML वैलिडेटर well-formedness जाँचता है, XSD नहीं)।

Responses को XPath से assert किया जाता है, जो XML documents के लिए एक query language है: //ord:status उस namespace के हर status element को चुनता है जिसे test tool ने ord prefix से जोड़ा है, response ख़ुद चाहे कोई भी prefix इस्तेमाल करे। Tester किसी response की text की तरह तुलना कभी नहीं करता।

ORD-1042 के लिए valid request: HTTP 200 और service namespace में GetOrderStatusResponse, जो XSD के अनुसार valid हो।
न मौजूद order ORD-99999999: WSDL में declared fault, जैसे OrderNotFound, न कि खाली body के साथ 200।
Well-formed नहीं, जैसे <ord:orderId> को </ord:orderID> से बंद करना: Client fault, कभी HTML page नहीं। किसी भी faultstring में stack traces, class names, SQL या file paths न हों।
Invalid: orderId गायब, prefix के बिना 1042, बिना किसी digit के या नौ digits के साथ ORD- (1 और 8 की boundaries के ठीक बाहर), includeItems में yes, या elements का क्रम उलटा: field का नाम बताने वाला Client fault। इनमें से कोई accept हो जाए, तो service input validate नहीं करती; पूछें कि क्या यह जानबूझकर है।
Envelope: text/xml के साथ भेजा गया SOAP 1.2 namespace वाला envelope VersionMismatch पाता है; body से मेल न खाने वाला SOAPAction कभी कोई दूसरा operation नहीं चलाता।
Envelope से पहले <!DOCTYPE> को fault के साथ reject होना चाहिए: दोनों SOAP versions message में document type declaration मना करते हैं, और इसे स्वीकार करने वाला parser XML external entity (XXE) attacks के लिए खुला हो सकता है। ऐसे checks सिर्फ़ उन systems पर चलाएँ जिन्हें टेस्ट करने की आपको अनुमति हो।

आज़माएँ: SOAP रिक्वेस्ट टेस्टर आज़माएँ: XML वैलिडेटर

आम गलतियाँ

SOAP response को HTTP status से आँकना: SOAP 1.1 में 500 गलत input का सही जवाब हो सकता है, और 200 में data के रूप में लौटाई गई error हो सकती है।
XML की text की तरह तुलना करना या ns2: जैसे prefixes पर assert करना; equivalent messages attribute order, indentation और prefixes में अलग हो सकते हैं।
हाथ से लिखा XML well-formed है या नहीं, यह जाँचे बिना भेजना, और फिर सही Client fault को defect बताना।
सिर्फ़ valid envelopes टेस्ट करना, हर required element, type, pattern और allowed values की list (enumeration) को, और elements के क्रम को तोड़े बिना।
यह मान लेना कि server requests को XSD के against validate करता है। यह configuration का फ़ैसला है: एक invalid message भेजकर देखें।

QA का नज़रिया

SOAP project में WSDL से शुरू करें, जैसे OpenAPI document से करते हैं: operations और declared faults की सूची बनाएँ, और required elements, types और limits के लिए XSD पढ़ें। जल्दी तय करें कि कौन-सा SOAP version है, क्या requests schema से validate होती हैं, और कौन-सी business errors सामान्य responses की जगह faults के रूप में आती हैं।

Request envelopes को versioned test data के रूप में रखें, हर check के लिए एक। Bug report में endpoint, SOAP version, SOAPAction, पूरे request और response envelopes और HTTP status दें: XML में अक्सर एक गलत character या namespace ही पूरा defect होता है।

अभ्यास

SOAP 1.1 service के पाँच responses की review करें

आपका काम

एक साथी ने test environment पर एक SOAP 1.1 service के CreateCustomer operation को पाँच requests भेजीं और लिखा कि क्या भेजा (sent) और क्या वापस आया (got)। हर run के लिए तय करें कि व्यवहार सही है या defect, और क्यों।

सामग्री

Operation: CreateCustomer   SOAP 1.1   test environment
Schema:    name   xs:string, maxLength 50, required
           email  xs:string, required
WSDL:      declared fault DuplicateEmail

Run 1  sent: <cus:name>Smith &amp; Sons</cus:name>, valid email
       got:  200, <cus:name>Smith &amp; Sons</cus:name> in the response
Run 2  sent: <cus:Email>sara@example.com</cus:Email>  (no <cus:email>)
       got:  200, customer C-381 created with no email
Run 3  sent: valid request, email already registered
       got:  500, faultcode soap:Client, detail <cus:DuplicateEmail/>
Run 4  sent: valid request while the database is stopped
       got:  500, faultcode soap:Client, faultstring "Invalid request"
Run 5  sent: envelope without </soap:Body>
       got:  500, Content-Type text/html, page shows a Java stack trace

चरण

हर run के लिए schema, WSDL और SOAP 1.1 rules से expected HTTP status, fault code और body लिखें।
हर run को सही या defect चिह्नित करें, और हर defect का एक line का bug title लिखें।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

Run 1: सही। Expected 200 और customer का बनना: XML में & को & के रूप में escape किया गया और वह बिना बदले लौटा; stored नाम Smith & Sons है।

Run 2: defect। XML names case-sensitive हैं, इसलिए <cus:Email> अनजान है और ज़रूरी email गायब है; 500 के साथ email का नाम बताने वाला Client fault आना चाहिए था, यानी service अपने schema से validate नहीं करती। Title: "CreateCustomer ज़रूरी email के बिना customer बना देता है"।

Run 3: सही। SOAP 1.1 हर fault पर 500 लौटाता है, और declared DuplicateEmail detail के साथ Client caller को बताता है कि क्या सुधारना है।

Run 4: defect। Request valid थी, इसलिए expected जवाब 500 के साथ Server fault है; Client fault callers से एक सही message बदलने को कहता है और उनके retries रोक देता है। Title: "Database बंद होने पर CreateCustomer, Client fault लौटाता है"।

Run 5: defect। Malformed XML को 500 और text/xml के रूप में भेजे गए SOAP envelope में Client fault मिलना चाहिए; HTML page SOAP clients को तोड़ता है और stack trace अंदरूनी जानकारी उजागर करता है। Title: "Malformed XML पर CreateCustomer, stack trace वाला HTML page लौटाता है"।

अक्सर पूछे जाने वाले सवाल

अगर मैं REST जानता हूँ, तो क्या SOAP सीखना ज़रूरी है?

हाँ, अगर आप organisations के बीच integrations या लंबे समय से चल रहे enterprise systems टेस्ट करेंगे, जहाँ SOAP अब भी आम है। REST में सीखी ज़्यादातर बातें — contracts, negative tests, सटीक bug reports — यहाँ भी काम आती हैं, और SOAP इनमें strict XML, एक formal WSDL contract और structured faults जोड़ता है।

Well-formed और valid XML में क्या फ़र्क़ है?

Well-formed का मतलब है document XML के syntax rules मानता है: एक root, बंद और सही तरह nested elements, quotes में attributes, escaped special characters। Valid का मतलब है वह well-formed है और किसी schema से भी मेल खाता है, जैसे WSDL में दिया XSD। जो document well-formed नहीं, parser को उसे reject करना ही होगा; और कोई document well-formed होकर भी invalid हो सकता है।

क्या मैं SOAP service को REST tool से टेस्ट कर सकता हूँ?

हाँ। SOAP request XML body वाली एक HTTP POST है, इसलिए custom headers के साथ raw body भेजने वाला कोई भी tool काम करता है। Content-Type और SOAP 1.1 में SOAPAction आपको ख़ुद set करने होंगे। Dedicated SOAP tools, WSDL से requests बनाने जैसी सुविधाएँ जोड़ते हैं।

कैसे पता करें कि service SOAP 1.1 इस्तेमाल करती है या 1.2?

WSDL की binding देखें: SOAP 1.1 binding namespace http://schemas.xmlsoap.org/wsdl/soap/ इस्तेमाल करती है और SOAP 1.2 binding http://schemas.xmlsoap.org/wsdl/soap12/। कोई service दोनों दे सकती है, हर एक के लिए अलग port के साथ। किसी चलती request में envelope namespace और Content-Type (text/xml या application/soap+xml) भी यही बताते हैं।

संदर्भ

Extensible Markup Language (XML) 1.0 (Fifth Edition)W3C · 2008XML दस्तावेज़ को वेल-फ़ॉर्म्ड क्या बनाता है: एलिमेंट, एट्रिब्यूट, एंटिटी, कैरेक्टर एन्कोडिंग और प्रोलॉग।
SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)W3C · 2007SOAP 1.2 messaging framework: वैकल्पिक header और अनिवार्य body वाला XML envelope, fault element और intermediaries के लिए processing model।
OWASP Cheat Sheet Series: Web Service SecurityOWASP FoundationSOAP और XML वेब सर्विस को सुरक्षित करना: ट्रांसपोर्ट सुरक्षा, मैसेज अखंडता, स्कीमा वैलिडेशन और XML-विशिष्ट हमले।
OWASP Cheat Sheet Series: XML External Entity PreventionOWASP FoundationXML पार्सर को बाहरी एंटिटी और DTD क्यों बंद रखने चाहिए, और आम पार्सर को सुरक्षित कैसे कॉन्फ़िगर करें।

XML और SOAP

यह क्यों ज़रूरी है

XML basics: well-formed, valid और namespaces

SOAP envelope और उसकी HTTP binding

WSDL: SOAP service का contract

SOAP faults: तय structure वाली errors

Worked example: GetOrderStatus की टेस्टिंग

आम गलतियाँ

QA का नज़रिया

अभ्यास

SOAP 1.1 service के पाँच responses की review करें

अक्सर पूछे जाने वाले सवाल

संदर्भ

Mutqan tools से अभ्यास करें

SOAP रिक्वेस्ट टेस्टर

XML वैलिडेटर

XML फ़ॉर्मेटर

XML से JSON

और गहराई से

इस topic में आपकी प्रगति

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

यह क्यों ज़रूरी है

XML basics: well-formed, valid और namespaces

SOAP envelope और उसकी HTTP binding

WSDL: SOAP service का contract

SOAP faults: तय structure वाली errors

Worked example: GetOrderStatus की टेस्टिंग

आम गलतियाँ

QA का नज़रिया

अभ्यास

SOAP 1.1 service के पाँच responses की review करें

अक्सर पूछे जाने वाले सवाल

संदर्भ

Mutqan tools से अभ्यास करें

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics