تست SOAP و REST؛ Contract، Fault و Evidence

مقایسهٔ SOAP و REST وقتی مفید است که از شعار «قدیمی در برابر مدرن» عبور کنیم. SOAP یک پروتکل پیام‌رسانی است؛ REST یک سبک معماری است. یکی را نمی‌توان فقط با XML و دیگری را فقط با JSON تعریف کرد. برای تست، نام فناوری کافی نیست: Contract واقعی، Binding، Schema، HTTP semantics، Business rule، State، Fault، امنیت و Evidence باید نسخه‌دار و قابل‌ردیابی باشند.

این راهنما یک Contract Test Matrix مشترک برای سرویس SOAP و API مبتنی بر HTTP می‌سازد. WSDL/XSD و OpenAPI را درست مرزبندی می‌کند، Fault و status را از Business outcome جدا می‌سازد، Retry و Idempotency را با واقعیت عملیات می‌سنجد و یک آزمایش کاملاً آفلاین فارسی ارائه می‌دهد؛ بدون Endpoint، Credential، شبکه یا سرویس واقعی.

خلاصهٔ اجرایی تست SOAP و REST

ابتدا نوع Interface را از روی Contract و Binding تشخیص دهید، نه پسوند URL یا فرمت Body.
برای SOAP، Envelope/Header/Body/Fault، Namespace، XSD، WSDL operation و Binding را تست کنید.
برای HTTP API، Resource، Method semantics، status، header، representation، cache و content negotiation را تست کنید.
WSDL/OpenAPI محدودهٔ Interface را توصیف می‌کنند؛ Business correctness، side effect و authorization هنوز Oracle جدا می‌خواهند.
Timeout را Failure قطعی ندانید و Retry را بدون Safe/Idempotent/duplicate contract اجرا نکنید.
هیچ‌کدام ذاتاً سریع‌تر، امن‌تر یا مناسب‌تر نیست؛ ادعا را در Context و با آزمایش همسان بسنجید.

Contract → Message/HTTP semantics → Business oracle → State/side effect → Fault/recovery → Evidence

SOAP چیست؟ پروتکل پیام، نه مترادف XML API

SOAP Version 1.2 Part 1 یک Messaging Framework توسعه‌پذیر بر پایهٔ فناوری‌های XML تعریف می‌کند که می‌تواند روی پروتکل‌های زیرین مختلف Bind شود. پیام SOAP Envelope دارد و ممکن است Header و Body داشته باشد؛ Fault نیز ساختار خطای پروتکلی است. هر XML روی HTTP، SOAP نیست و هر SOAP را نباید صرفاً «یک POST XML» دید.

SOAP message identity:
soap_version + envelope_namespace + binding + operation/action
+ header blocks + body QName + schema version + policy profile

REST چیست؟ سبک معماری، نه پروتکل JSON

رسالهٔ Roy Fielding REST را سبک معماری و مجموعه‌ای از Constraintها برای سیستم‌های Hypermedia توزیع‌شده معرفی می‌کند. Resource identification، representation، uniform interface، stateless interaction، cache و layered system در تحلیل اهمیت دارند. یک API با Endpointهای فعلی ممکن است HTTP+JSON باشد، اما همهٔ Constraintهای REST را پیاده نکند.

Stateless یعنی هر Request زمینهٔ لازم تعامل را حمل کند؛ نه اینکه Business state وجود نداشته باشد.
Representation خود Resource نیست و می‌تواند Media typeهای متفاوت داشته باشد.
JSON الزامی نیست؛ XML، متن، باینری یا Media type اختصاصی ممکن است.
نام Path به‌تنهایی semantics را تعیین نمی‌کند؛ Method/Header/Contract نیز لازم‌اند.

چرا «SOAP در برابر REST» مقایسهٔ کاملاً متقارن نیست؟

SOAP مجموعهٔ قواعد پیام‌رسانی و Extensibility دارد؛ REST محدودیت‌های معماری را توصیف می‌کند. مقایسهٔ عملی بهتر است بین دو Interface مشخص باشد: مثلاً SOAP ۱.۱/WSDL ۱.۱ روی HTTP با WS-Security profile معین، در برابر یک HTTP API با OpenAPI ۳.۱، Bearer token و JSON. بدون نسخه و Profile، نتیجه فقط کلیشه است.

بعد	SOAP interface	HTTP API با طراحی REST-oriented
واحد تعامل	Message/Operation/MEP	Resource/Method/Representation
توصیف رایج	WSDL + XSD + Policy	OpenAPI + Schema + policy docs
خطای Interface	SOAP Fault و Binding behavior	HTTP status + headers + error representation
Dispatch	Operation/action/body QName طبق Binding	Method + target URI + media negotiation
Cache/Retry	Binding و application contract	HTTP semantics + application contract
امنیت	Transport/message/policy profile	Transport/authn/authz/message controls

قبل از تست، Interface Inventory بسازید

Hostname به‌تنهایی Scope نیست. Environment، Service/Endpoint، Contract URL یا Artifact، نسخه، Hash، Operation/Path، Consumer، داده، Authentication profile، Timeout، Retry owner و Deprecation window را ثبت کنید. Import و Referenceهای بیرونی را نیز Pin کنید؛ Contractی که امروز فایل دیگری را می‌خواند ممکن است فردا بدون تغییر نسخه رفتار دیگری داشته باشد.

interface_id و owner
SOAP/WSDL/XSD یا HTTP/OpenAPI version
binding/transport/media type
operation/action یا path/method
consumer/provider و compatibility window
security profile و test identity
timeout/retry/idempotency semantics
artifact hash/retrieval date/deprecation

interface_id: IF-SYN-QUOTE-01
contract: local-artifact.invalid / pinned hash
network: disabled
consumer/provider: fictional
decision_scope: contract review only

WSDL و XSD چه چیزی را توصیف می‌کنند؟

WSDL 2.0 Core Interface، Operation، Binding، Service و Endpoint را مدل می‌کند و XML Schema می‌تواند Typeها و Elementها را تعریف کند. اما بسیاری از سامانه‌های واقعی WSDL ۱.۱ دارند؛ Tester باید نسخهٔ Artifact واقعی را Pin کند، نه اینکه صرفاً چون WSDL ۲.۰ Recommendation جدیدتر است Contract را ارتقا دهد.

QName و Namespace هر Element/Type
Operation و Message Exchange Pattern
Input/Output/Fault references
Binding و underlying protocol
Service/Endpoint address در هر Environment
Import/Include و Schema-location resolution
Optional/required، cardinality، restriction و sequence

OpenAPI ۳.۲.۰ چه چیزی را توصیف می‌کند؟

OpenAPI 3.2.0 در ۱۹ سپتامبر ۲۰۲۵ منتشر شده و نسخهٔ منتشرشدهٔ جاری است. OAS یک توصیف زبان‌ناوابسته برای HTTP API می‌دهد تا انسان و ابزار Capability را بفهمند. نسخهٔ Contract محصول شما ممکن است ۳.۱ یا ۳.۰ باشد؛ Toolchain compatibility را بسنجید و از ارتقای خودکار به ۳.۲ فقط برای «جدید بودن» پرهیز کنید.

servers و variables
paths/operations و parameters
request bodies و media types
responses/status/headers/content
schemas/examples و reusable components
security schemes/requirements
callbacks/webhooks و external references در صورت استفاده

Contract Source of Truth را تعیین کنید

Design-first، code-first یا registry-first هرکدام ممکن‌اند؛ مشکل وقتی است که چند Artifact هم‌زمان Authority ادعا می‌کنند. Source، generator، version، approval، compatibility policy و Correction path را مشخص کنید. Generated client یا mock باید Derivative باشد و Hash آن به Contract مرجع وصل شود.

authority: approved_contract_artifact
derived: client_stub, mock, docs, tests
drift_rule: derived_hash must reference authority_hash
correction: fix source, regenerate, reverify

Schema-valid بودن، درستی کسب‌وکار را اثبات نمی‌کند

XSD یا OpenAPI Schema می‌تواند Shape، Type و Constraintهای بیان‌شده را بررسی کند؛ اما اینکه مبلغ درست محاسبه شده، Actor مجاز بوده، State انتقال یافته یا Side effect دقیقاً یک‌بار رخ داده را ثابت نمی‌کند. Schema validation لازم است، ولی Oracle کسب‌وکار، State store و downstream effect نیز باید Evidence بدهند.

valid_shape ∧ wrong_owner = business failure
valid_status ∧ duplicate_effect = integrity failure
valid_fault ∧ leaked_secret = security failure

Namespace در SOAP: Prefix مهم نیست، URI مهم است

دو Prefix متفاوت می‌توانند به یک Namespace URI اشاره کنند و معنای یکسان داشته باشند؛ در مقابل Element با Local name مشابه و Namespace متفاوت یکسان نیست. Assertion متنی روی Prefix یا ترتیب Attribute شکننده است. QName، Namespace URI، Schema type و جایگاه Element را بررسی کنید. اگر XSD sequence دارد، ترتیب Childها ممکن است الزام Contract باشد.

compare: {namespace_uri}local_name
do_not_compare: literal prefix spelling
order: enforce only where contract/schema requires it

Envelope، Header و mustUnderstand

نسخهٔ Envelope، Header blockها، Role/Relay و قواعد پردازش باید از SOAP version و Profile واقعی بیایند. Header ناشناختهٔ Required، Duplicate security block، Correlation ناهماهنگ و Body خالی را به‌صورت کنترل‌شده در Harness محلی بررسی کنید. نتیجهٔ مورد انتظار را از Binding/Policy استخراج کنید، نه از رفتار تصادفی یک Client.

Operation و Action را از Binding بخوانید

در SOAP ۱.۱، SOAPAction HTTP header رایج است؛ در SOAP ۱.۲، action می‌تواند پارامتر Media type باشد. Frameworkها ممکن است Dispatch را با Action، Body QName یا Route ترکیب کنند. Test matrix باید نسخه، Content-Type، Action form، Operation و mismatch behavior را Pin کند؛ یک Header ثابت برای همهٔ سرویس‌ها نسخه‌ناوابسته نیست.

SOAP Fault را به Business Error تقلیل ندهید

Fault ساختار خطای SOAP است و Code/Reason/Node/Role/Detail می‌تواند داشته باشد. Business rejection ممکن است Fault یا پاسخ عادیِ Domain باشد؛ این تصمیم Contract است. HTTP status نیز به Binding وابسته است. بنابراین فقط «status=۵۰۰» یا جست‌وجوی متن پیام Oracle کافی نیست؛ Fault QName، detail schema، correlation و side effect را بررسی کنید.

fault_oracle:
transport_status + envelope_version + fault_code_qname
+ detail_schema + correlation + expected_side_effect_state

HTTP semantics را از RFC ۹۱۱۰ بگیرید

RFC 9110 Semantics مشترک HTTP را برای Method، status، field و representation تعریف می‌کند. Safe و Idempotent ویژگی Method semantics هستند، نه وعده‌ای که از نام Endpoint حدس بزنیم. GET نباید به درخواست کاربر State هدف را تغییر دهد؛ PUT و DELETE idempotent تعریف شده‌اند، ولی Retry عملی هنوز باید Timeout، concurrent actor و side effect بیرونی را ببیند.

Method و target resource
Precondition و conditional headers
Request/response content و media type
Status و header semantics
Cacheability/validators/Vary
Safe/idempotent expectations
Redirect و authentication challenge behavior

HTTP ۲۰۰ مساوی موفقیت کسب‌وکار نیست

۲xx موفقیت پردازش در سطح HTTP را بیان می‌کند، نه لزوماً تحقق Rule محصول. برخی APIها خطای Domain را در Body با ۲۰۰ می‌فرستند؛ این انتخاب ممکن است Contract موجود باشد، هرچند Visibility را کاهش دهد. در سوی دیگر، 4xx/5xx نوع Failure را بدون خواندن Representation کامل نمی‌کند. Transport، Protocol و Business verdict را جدا ثبت کنید.

verdict = {
  transport, protocol, contract, business, state, side_effect, security
}
overall cannot be inferred from status alone.

Content Negotiation و Media Type

Content-Type می‌گوید Content چگونه تفسیر شود و Accept ترجیح Representation پاسخ را منتقل می‌کند. Missing/unsupported media type، charset، language و compression را طبق Contract بررسی کنید. JSON parser ممکن است عدد یا Unicode را متفاوت مدیریت کند؛ XML declaration و Encoding نیز باید با Bytes سازگار باشد.

Missing، Null، Empty و xsi:nil

نبود Property، مقدار null، رشتهٔ خالی و آرایهٔ خالی چهار State معنایی متفاوت‌اند. در XML نیز absent element، empty element و xsi:nil لزوماً یکسان نیستند و XSD nillable/minOccurs روی پذیرش اثر دارد. Mapping بین SOAP و REST باید این Semantic delta را صریح کند؛ Generator ممکن است آن‌ها را بی‌صدا یکی کند.

حالت	XML نمونهٔ مفهومی	JSON نمونهٔ مفهومی	Oracle
Missing	Element وجود ندارد	Property وجود ندارد	Default/required policy
Null/Nil	xsi:nil طبق Schema	null طبق Schema	Explicit unknown/cleared semantics
Empty text	Element بدون متن	“”	Length/domain rule
Empty collection	Container بدون item	[]	Cardinality/business rule

عدد، پول و زمان را رشتهٔ ساده نبینید

Decimal precision، scale، range و rounding باید Contract داشته باشد. در بازار ایران، canonical IRR را از display-only تومان با نسبت صریح ۱:۱۰ جدا کنید؛ ارقام فارسی/عربی/لاتین فقط Presentation هستند مگر Contract خلافش را بگوید. Timestamp باید offset/zone/precision و semantics داشته باشد؛ تاریخ جلالی را لایهٔ نمایش بدانید مگر Domain contract صریحاً Canonical کند.

money = amount_minor_or_units + currency + scale + rounding_policy
time = instant_or_local + offset/zone + precision + business_calendar
display never overwrites canonical value.

Unicode، RTL و Normalization در هر دو Interface

ی/ی، ک/ک، ZWNJ، ترکیب حروف، Emoji، Bidi control و طول بر حسب Byte/Code point/Grapheme می‌توانند Contract را بشکنند. Normalization را بی‌اجازه اعمال نکنید؛ Canonical form و Display form را جدا کنید. XML/JSON serializer، database، log و downstream consumer را در یک Trace بررسی کنید.

round-trip بدون از دست‌دادن Meaning
length/validation unit مشخص
sorting/search normalization policy
log/trace امن و قابل‌خواندن RTL
mixed-direction identifier rendering

State و Side Effect را جدا از Response بسنجید

Response درست می‌تواند همراه Side effect غلط باشد و Response قطع‌شده ممکن است پس از Commit رخ دهد. Oracle چندلایه بسازید: Payload، persisted state، event، audit و downstream effect. Correlation/Business IDها را بدون Secret ثبت کنید تا یک Intent در مرزها دنبال شود.

request_intent → accepted? → committed? → emitted? → observed? → reconciled?
unknown at any boundary remains UNKNOWN until authoritative inquiry/reconciliation.

Timeout، Retry و Idempotency

Timeout فقط می‌گوید Client در بازهٔ انتظار پاسخ نگرفت؛ نمی‌گوید Provider Commit نکرده است. برای هر Operation مشخص کنید Retry مجاز است یا نه، چه Key/Scope/Fingerprintی دارد، concurrent duplicate چه می‌شود، نتیجهٔ قبلی چگونه replay می‌شود و Unknown چگونه Inquiry/Reconciliation می‌شود. SOAP/REST بودن پاسخ این Contract را خودکار نمی‌سازد.

timeout-before-commit
timeout-after-commit-before-response
duplicate same payload/key
same key/different payload conflict
concurrent duplicates
late/out-of-order response/event
key expiry and replay horizon

برای ساخت Harness چندلایه، راهنمای تست API پیشرفته از Contract تا Oracle و Idempotency مرجع مکمل است.

Security profile را از فرمت پیام استنتاج نکنید

SOAP ذاتاً امن‌تر نیست و REST نیز صرفاً با HTTPS کامل نمی‌شود. WS-Security SOAP Message Security 1.1.1 مدل Token و یکپارچگی/محرمانگی سطح پیام ارائه می‌کند، اما فقط وقتی Profile، Algorithm، Key lifecycle، Canonicalization، Actor و پردازش درست باشند. سمت HTTP نیز TLS، Authn، Authz، audience/scope، replay و object-level controls لازم‌اند.

Transport confidentiality/integrity و endpoint identity
Message signature/encryption profile در صورت استفاده
Authentication، authorization و least privilege
Freshness، replay و correlation
Secret/token redaction و rotation
Parser/resource limits و safe failure
Audit integrity و retention

XML parser boundary و XXE

راهنمای رسمی OWASP برای پیشگیری XXE بر غیرفعال‌کردن DTD/external entities و external DTD loading، محدودیت expansion و جلوگیری از fetch بیرونی تأکید می‌کند. Test باید Config parser واقعی را از Owner بگیرد و در Harness ایزوله بررسی کند؛ Payload ناشناس را روی سرویس واقعی امتحان نکنید.

برای Threat boundary و تست ایمن‌تر، راهنمای SSRF و XXE را ببینید.

Attachment و Payload بزرگ

SOAP ممکن است Attachment/MTOM و HTTP API ممکن است multipart یا binary media type داشته باشد. Size limit، content type، checksum، streaming، partial read، cleanup و malware-control contract را جدا بررسی کنید. Base64 حجم را تغییر می‌دهد؛ اما نتیجهٔ Performance را باید با Byte count و مسیر واقعی اندازه گرفت، نه با برچسب SOAP/REST.

آیا REST همیشه سریع‌تر از SOAP است؟

خیر. Encoding، payload shape، compression، connection reuse، TLS، network، parser، framework، cache، server work، downstream و observability بر latency/CPU/memory اثر دارند. یک نمونهٔ JSON کوچک در برابر SOAP production-equivalent مقایسهٔ معتبر نیست. Workload، semantics، data، environment و warm-up را Match کنید و Distribution را گزارش دهید.

matched trial:
same business outcome + equivalent data + same environment/window
+ byte counts + client/server resources + error rate + latency distribution

Contract Test، CDC و E2E را لایه‌بندی کنید

Schema/contract test سریع Drift را می‌گیرد؛ Provider component test Business implementation را می‌سنجد؛ Consumer-driven contract انتظار Consumer را آشکار می‌کند؛ Integration binding/security/network را بررسی می‌کند؛ E2E Outcome محدود را پوشش می‌دهد. هیچ لایه‌ای جای همه را نمی‌گیرد. برای انتخاب به راهنمای CDC در برابر E2E و راهنمای Pact رجوع کنید.

لایه	سؤال	سرعت/فیدلیتی	Gap
Lint/schema	Artifact از قواعد پیروی می‌کند؟	سریع/کم	Business و runtime
Provider component	Implementation contract را اجرا می‌کند؟	سریع-میانه	شبکه/consumer واقعی
CDC	Provider انتظار نسخه‌دار consumer را نمی‌شکند؟	میانه	Outcome کامل
Virtualized integration	Fault/retry مسیر کنترل‌شده درست است؟	میانه	Provider fidelity
Bounded E2E	Outcome حیاتی در stack واقعی رخ می‌دهد؟	کند/بیشتر	همهٔ حالات

Service Virtualization و Fidelity

Mock فقط رفتارهایی را می‌داند که تیم مدل کرده است. Contract version، matcher strictness، state model، latency/fault schedule، owner و expiry را ثبت کنید. برای HTTP dependencyها راهنمای WireMock مفید است؛ برای SOAP نیز Harness محلی باید Namespace/Fault/Action را واقعاً مدل کند، نه پاسخ ثابت خوش‌بینانه.

virtualization_claim:
implements scenarios S1..Sn of contract hash H
does_not_claim: provider availability, full policy, performance, production parity

Versioning و Backward Compatibility

افزودن Field optional همیشه سازگار نیست: Consumer ممکن است Unknown field را Reject کند، Enum جدید را نشناسد یا Generator آن را به Default غلط تبدیل کند. در XSD نیز Namespace، min/maxOccurs، restriction و ترتیب اثر دارند. Matrix نسخهٔ Consumer×Provider بسازید و Compatibility را با Artifact واقعی و replay نمونهٔ پالایش‌شده بررسی کنید.

add/remove/rename field یا element
required↔optional و default
type/range/format/precision
enum expansion
namespace/media type/action/path
fault/error representation
security/policy requirement
deprecation, overlap and rollback window

Tool انتخاب کنید، نه Tool worship

SoapUI، Postman، code-based harness، schema validator و generated client قابلیت‌های متفاوت دارند. ابتدا Requirement matrix بسازید: WSDL/OpenAPI version، WS-Security، Namespace assertions، scripting/runtime، CLI/CI، report، secret handling، offline support، license و Iran access/continuity. سپس PoC همسان اجرا کنید.

برای Workspace و Handoff به راهنمای Postman Workspace مراجعه کنید؛ این صفحه هیچ ابزار واحدی را برای SOAP/REST برنده اعلام نمی‌کند.

Evidence و Observability

Evidence باید Contract hash، Build، Environment fingerprint، Case/Claim، sanitized request/response digest، correlation، state/side-effect proof، timing و Verdict داشته باشد. Password، token، cookie، signature material، PII و payload کامل را در Ticket نگذارید. Trace باید بین SOAP/REST gateway و downstreamها Meaning را حفظ کند.

evidence_id | interface | contract_hash | build | case | verdict | trace | redaction | retention
EV-SYN-31 | IF-SYN-01 | H-SYN | B-SYN-4 | C-07 | fail | T-SYN | complete | 7d

سناریوی ایرانی کاملاً مصنوعی

یک سرویس خیالی Quote برای سفارش فارسی دو Interface آموزشی دارد: SOAP Operation با XSD و HTTP resource با OpenAPI. هدف، مقایسهٔ Semantic outcome است، نه اثبات برابری Wire. داده‌ها شامل Customer ساختگی، مبلغ فرضی IRR، نمایش صریح تومان، Unicode فارسی و زمان است؛ هیچ بانک، دولت، Provider، شخص، پرداخت یا تراکنش واقعی وجود ندارد.

Canonical amount: ۱,۲۵۰,۰۰۰ IRR ساختگی
Display: ۱۲۵,۰۰۰ تومان با Label
Names: «مشتری آزمایشی» و variants ی/ی، ک/ک
Time: Instant UTC + نمایش Asia/Tehran
Operations: create quote / read quote، فقط Artifact متنی
Faults: schema mismatch، duplicate، timeout state، همگی از پیش‌ساخته

آزمایش آفلاین SYN-SOAP-REST-IR-۰۱

آزمایش هیچ Requestی ارسال نمی‌کند. دو Manifest، دو Contract fragment و شش Evidence record ساختگی را می‌خواند. Checker سطحی با دیدن WSDL/OpenAPI و status ۲۰۰ به‌اشتباه Ready می‌شود؛ Checker قراردادمحور ۸۵۶ Control گروه‌بندی‌شده را برای Identity، Shape، Semantics، State، Fault، Security، Compatibility و Evidence بررسی می‌کند.

lab_id: SYN-SOAP-REST-IR-01
network/endpoints/credentials: none
superficial: SOAP_ENTERPRISE_REST_FAST_JSON_BEST_WSDL_OPENAPI_COMPLETE_200_OK_READY
contract_result: HOLD-856

Oracle و Exit آزمایش

هر Interface نسخه، Binding، Contract hash و Authority دارد.
Transport/Protocol/Contract/Business/State/Security verdict جداست.
Namespace و Missing/Null/Empty semantics Pin شده است.
Timeout/duplicate به Success یا Failure قطعی تبدیل نشده است.
Schema pass به Business pass تعمیم نیافته است.
هیچ Endpoint، Credential، Payload حمله یا تصمیم واقعی وجود ندارد.

NO_REAL_ENDPOINT_USER_ACCOUNT_CREDENTIAL_SECRET_PERSON_PAYMENT_BANK_GOVERNMENT_SERVICE_NETWORK_TRANSACTION_PRODUCTION_OR_RELEASE_DECISION_PASS
READY_FOR_SOAP_REST_CONTRACT_MATRIX_REVIEW-0

چه زمانی SOAP، REST یا gRPC را انتخاب کنیم؟

انتخاب معماری خارج از نتیجهٔ یک تست است. Consumer ecosystem، Governance، message-level security، schema/tooling، browser/cache، streaming، latency، compatibility و operating skill را وزن دهید. برای گزینهٔ Protobuf/Streaming، راهنمای تست gRPC مکمل است. Migration نیز باید Dual-run، reconciliation، cutover و rollback داشته باشد.

نقشهٔ تست ۳۰ روزه

هفتهٔ اول: Interface inventory، Authority و Consumer×Provider matrix را کامل کنید.
هفتهٔ دوم: Schema/semantics/Business oracle و Fault catalog را روی Artifactهای محلی بسازید.
هفتهٔ سوم: timeout/duplicate/version/security-profile cases را در virtualization کنترل‌شده تمرین کنید.
هفتهٔ چهارم: Pilot محدود را با Evidence، gap، cost و KEEP/ADAPT/STOP بازبینی کنید.

ضدالگوهای رایج

SOAP=امن/کند/Enterprise و REST=سریع/JSON/مدرن
تشخیص Success فقط از HTTP ۲۰۰
اعتماد کامل به WSDL/OpenAPI یا generated client
Assertion روی XML prefix یا JSON property order
یکسان‌گرفتن missing/null/empty
Retry خودکار هر Operation پس از timeout
Schema pass به‌عنوان Business/authorization pass
Mock ثابت با ادعای Production parity
Log کامل پیام با Token/PII/Signature
مقایسهٔ Performance با Payload و محیط نامتوازن
Upgrade Contract بدون Tool/consumer compatibility
آزمون Security ناشناس روی Endpoint واقعی

چک‌لیست نهایی Contract Test Matrix

نوع Interface، نسخه و Binding دقیق است.
Contract Authority، Hash، Import/Ref و Consumerها ثبت‌اند.
Operation/Action یا Resource/Method/Media semantics روشن‌اند.
Shape، Namespace، nullability، number/time/Unicode پوشش دارند.
Business/State/Side effect Oracle مستقل است.
Fault/status/error representation و correlation تست شده‌اند.
Timeout/Retry/Idempotency/Unknown قرارداد دارند.
Security profile، parser limits و secret redaction بررسی شده‌اند.
CDC/virtualization/E2E سهم و Gap مشخص دارند.
Compatibility/deprecation/rollback نسخه‌دارند.
Evidence به Build و Contract وصل و پالایش شده است.
نتیجه به SOAP/REST برتری جهانی تعمیم داده نمی‌شود.

برای مبانی عمومی‌تر، راهنمای تست API نقطهٔ شروع مناسبی است.

پرسش‌های متداول

تفاوت اصلی SOAP و REST چیست؟

SOAP یک Messaging protocol توسعه‌پذیر بر پایهٔ XML technologies است؛ REST یک Architectural style با Constraintهایی مانند uniform interface و stateless interaction. مقایسهٔ تست باید بین Interfaceهای نسخه‌دار و Profileهای واقعی انجام شود.

آیا WSDL و OpenAPI همهٔ Test Caseها را تولید می‌کنند؟

خیر. آن‌ها بخش مهمی از Interface contract را توصیف می‌کنند و برای تولید Check مفیدند، اما Business rule، authorization context، State، side effect، timeout ambiguity، عملیات و Risk را کامل اثبات نمی‌کنند.

برای SOAP باید فقط HTTP ۵۰۰ و برای REST فقط status code را تست کرد؟

خیر. SOAP Fault و HTTP binding/status باید طبق نسخه و Contract با هم خوانده شوند. در HTTP API نیز status فقط بخشی از Verdict است؛ headers، representation، Business outcome، State و side effect لازم‌اند.

آیا REST همیشه سریع‌تر و SOAP همیشه امن‌تر است؟

خیر. Performance به Workload/bytes/parser/network/server/cache و عوامل دیگر وابسته است. امنیت نیز به Threat model، TLS، Authn/Authz، message profile، key/token lifecycle و پیاده‌سازی بستگی دارد، نه نام Interface.

بعد از Timeout می‌توان Request را دوباره فرستاد؟

فقط با Contract روشن. Safe/Idempotent method semantics، Application idempotency key، fingerprint، concurrency، expiry و inquiry/reconciliation را بررسی کنید. Timeout ممکن است بعد از Commit و پیش از رسیدن Response رخ داده باشد.

جمع‌بندی: Protocol را به Evidence وصل کنید

تست SOAP و REST مسابقهٔ فناوری نیست. Interface را Inventory کنید، Contract و Binding را Pin کنید، Wire semantics را از Business/State جدا بسنجید، Fault و Timeout را مبهم نگه ندارید، Compatibility و Security profile را نسخه‌دار کنید و Evidence پالایش‌شده بسازید. خروجی خوب نمی‌گوید «REST برنده است»؛ دقیقاً می‌گوید کدام Claim در کدام Build و Contract با چه محدودیتی پشتیبانی می‌شود.

تست یکپارچه

تست SOAP و REST؛ از Contract تا Fault و Evidence