REST چیست!

[eshpilen]

In many references you will see REST and SOAP both mentioned as competitors. That is not true. SOAP is actually a protocol, not an architecture style. What REST can be compared against is SOA and RPC. All three are examples of web service styles, each with their own conceptual focus. RPC is focused around operations, SOA around messages, and REST around resources.

ترجمه: «در بسیاری از رفرنس ها شما REST و SOAP را ذکر شده بعنوان رقیب مشاهده میکنید. آن صحیح نیست. SOAP عملا یک پروتکل است، نه یک شیوهء معماری. آنچه REST میتواند با آن مقایسه شود SOA و RPC است. همهء این سه مثالهایی از شیوهء معماری وب سرویس هستند، هریک با تمرکز مفهومی خودش. RPC بر عملیات ها متمرکز است، SOA بر پیام ها، و REST بر منابع.»

منبع: http://phpmaster.com/rest-can-you-do-more-than-spell-it-1/

--------------------


این قضیه resource چیه؟

تاجاییکه از خوندن منابع فهمیدم، منظور از resource اینه که در سیستمهایی که بر اساس REST هستن ما همه چیز رو بصورت یکسری منابع میبینیم که این منابع با URI ها مشخص میشن. البته این URI ها لزوما ثابت نیستن و لزوما به آدرس فیزیکی یک منبع واقعی اشاره نمیکنن، بلکه انتزاعی هستن که REST استفاده میکنه. اصولا REST میگه که این URI ها به انتخاب سرور هستن و میتونن تغییر کنن (کلاینت باید اونا رو از خود سرور دریافت کنه) و خلاصه چیز فیکس شده ای در این زمینه وجود نداره. این یکی از شرایط RESTful بودن یک سیستم هست.
حالا شرایط دیگه چی و این شرایط میخوان چه اهدافی رو تامین کنن، علت وجودی REST است که تز دکترای آقای Roy Fielding بوده که ایشون یکی از مولفان اصلی پروتکل HTTP بوده بعلاوهء دخالت داشتن در چند پروژه و کارهای مهم دیگه (منجمله یکی از بنیانگذاران وب سرور آپاچی).
تاجاییکه فهمیدم، ایشون REST رو طوری طراحی کرده که درواقع همون مفاهیمی/معماری ای هست که وب بر اساس اونها ایجاد شد و توسعهء سریع و راحت و عمر طولانی اون با این مشخصات معماری بود که تامین شد و تجربه ثابت کرد که این اصول/ساختار، معماری مناسبی برای گسترش و تغییرات غیرقابل پیشبینی در طولانی مدت است.
مثلا یکی از شرایط دیگر RESTful بودن Stateless بودنه که میدونید پروتکل HTTP که وب روی اون اجرا میشه یک پروتکل Stateless هست.
شرایط دیگر شامل پیاده سازی به شکل Client–server است.
شرط دیگر Cacheable بودن (قابل کش بودن پاسخ ها).
شرط دیگر Layered system. به این معنی که لایه های میانجی مختلفی بتونن بصورت شفاف بین کلاینت و سرور قرار بگیرن (مانند سرورهای کش، پراکسی ها، فایروال ها، سرورهای load-balancing).
بعلاوهء یکی دوتا شرط دیگه که میشه گفت همش رو در معماری وب مشاهده میکنیم.

---------------------

در REST میتونید دیتای جانبی رو (مثل مقادیر فیلدهای یک فرم HTML) با هر فرمتی که میخواید ارسال کنید، اما اول نیاز به داشتن یک URI دارید (در HTML همون آدرس action فرم) که بگید این دیتا درمورد چه resource ای هست.
مثلا حتی اگر میخوای تایم سیستم رو بگیری، باید یک URI براش مشخص کنی؛ مثلا http://example.com/current_time
البته REST میگه پروتکل مشخص شده برای این URI میتونه هر چیزی باشه و به http محدود نمیشه.

با SOAP کار نکردم اما فکر میکنم نیازی به داشتن مفهوم resource و URI نداره.

البته اینم که REST از متدهای پروتکل انتقالی که استفاده میکنه (معمولا HTTP) استفاده میکنه، یکی از خصیصه های REST هست.
ولی این متدها (POST GET PUT DELETE) برای مشخص کردن ماهیت عملیات مورد نظر (ایجاد، خواندن، آپدیت، حذف) استفاده میشن و به فرمت دیتای ارسال شده ارتباطی ندارن. مثلا شما با متد POST میتونی هر نوع دیتایی رو با هر فرمتی منتقل کنی (طبیعتا در سمت دیگر با اون فرمت اصلی بازیابی و خونده میشه). POST فقط یک متد/فرمت انتقاله در سطح پروتکل HTTP، نه فرمت اولیه و بازیابی شدهء دیتای ارسال شده.

[eshpilen]

REST یک وب سرویس نیست. پروتکل هم نیست.
REST یک روش معماریه. یکسری اصول کلی.
حالا بر طبق این معماری و اصول میتونه سیستمهای مختلفی منجمله وب سرویس طراحی بشه که اونوقت به اون سیستم RESTful گفته میشه.
در تمام منابعی که این یکی دو روزه خوندم این مطلب تقریبا به وضوح اومده که REST یه معماری و ساختار کلی هست و نه پروتکل یا وب سرویس و یا حتی استاندارد.

SOAP خودش یه پروتکله، چون فقط یکسری اصول کلی برای طراحی یک سیستم رو معرفی نمیکنه، بلکه جزییات و اینترفیس و پروتکل تعریف میکنه.

ولی REST میتونه به شکلهای مختلفی و در سیستمهای مختلفی استفاده بشه و خودش به تنهایی یک مجموعهء کامل و دقیق از جزییات فنی نیست. بلکه یکسری موارد اساسی و کلی رو مشخص میکنه و میگه باید این خواص رو داشته باشن و بر این طرح کلی استوار باشن؛ بقیش رو دیگه طراحان سیستمها و پروتکل ها خودشون برحسب هر مورد طراحی میکنن.

--------------------

در REST هر درخواست باید با یک URI مشخص بشه.
ولی در پروتکل های بر اساس معماریهای دیگه مثل SOAP، یک URI میتونه عملا برای پاسخ دادن به هر تعدادی درخواست از هر نوعی استفاده بشه. البته تاجاییکه من از منابع فهمیدم؛ چون خودم عملا با SOAP کار نکردم و رفرنسش رو نخوندم.
مثلا در SOAP شما میتونی بجای اینکه منبع مورد نظر رو با URI مشخص کنی از عناصر XML استفاده کنی. مثلا:


<category name="books">
<category name="programming">
<book>PHP master</book>
</category>
</category>

میتونه برای سرور SOAP مشخص کنه که شما دنبال کتابها و بعد کتابهای برنامه نویسی و نهایتا کتاب PHP master هستی. حالا یا میخوای اطلاعات این کتاب رو دریافت کنی یا ایجاد کنی یا حذف کنی و غیره که اینا هم با عناصر و مشخصه های XML میتونن مشخص بشن.
ولی REST میگه منبع مورد نظر باید حتما با یک URI مشخص بشه. شما نمیتونی یک درخواست REST رو به یک URI کلی که همهء درخواستها رو تحویل میگیره و پردازش میکنه ارسال کنی. یعنی نمیتونی اطلاعات برای مشخص کردن منبع مورد نظر رو در جایی غیر از URI و مثلا با فرمت XML مشخص کنی.
در REST باید بجای کدهای XML بالا از یک URI مثلا به این شکل استفاده بشه:


http://example.com/books/programming/PHP_master

نمیتونی درخواستت رو به یک URI مشترک بفرستی و با پارامترهای دیگه منبع/شیء مورد نظر رو مشخص کنی.

ضمنا در REST استفاده از متدهای پروتکل انتقالی برای مشخص کردن نوع عملیات ضروری نیست، ولی شدیدا تشویق و پیروی میشه. یعنی بجای اینکه قراردادی رو خود برنامه نویسان برای مشخص کردن عملیات پایه مورد نظر طراحی کنن، ترجیح اکید اینه که از متدهای پروتکل انتقال برای رساندن این مفاهیم استفاده بشه.

---------------------

یک وبسرویس میتونه Restful باشه. اگر وب سرویس بر اساس معماری/اصول REST باشه میشه RESTful.

[eshpilen]

در بحثهایی که شده بودم چند بار از Roy Fielding یک نمونه کد و مثال واقعی خواسته بودن، اما چنین چیزی ارائه نکرده بود. البته توضیحاتش بد نبود و یک مقدار بیشتر وارد بعد فنی و ملموس قضیه شده بود در جواب. شاید بنظرش در یک چنین بحث تئوریکی، و از نظر یک تئوریسین، ارائه کد بجای تئوری کیفیت و دقت و کلیت مطلب رو کاهش میده.

بعدش خود منم الان بینش کامل و دقیق قاطع ندارم. بعضی جوانبش هنوز برای خودمم مبهمه یا حضور ذهن ندارم و نمیتونم توی ذهنم جمع و جورش کنم؛ شاید بخاطر اینکه بقیش دیگه باید عملی پیش بیاد و آدم تجربه کنه و احتمالا اونطوری با مثال هم بهتر میشه توضیح داد.

حتی اونهمه بحث و توضیحاتی که Roy Fielding داده بود بازم برای همه رفع ابهام نشده بود. کلا یه چیزی هست که خیلی ها توش مشکل و ابهام دارن یا بخشهایی از اون براشون معلوم نیست. حالا کم و زیاد داره. بعضیا که اصلا نمیدونن بحث سر چیه. مثلا فکر میکنن REST مثل یک جور پروتکل SOAP ساده شده هست (که خودمم تا همین چند روز پیش اینطور فکر میکردم).

اما چیزهایی که من اطمینان بیشتری ازشون دارم و میتونم براتون خلاصه کنم اینهاست (البته دیگه درست و غلطش رو من تضمین نمیکنم. ممکنه اشتباهاتی درش باشه):

- در یک سیستم بر اساسREST مفهوم پایه ای که ما باهاش کار میکنیم منبع (Resource) است. همه چیز رو بصورت یک منبع میبینیم (از دید کلاینت).
روی هر منبعی هم طبیعتا میتونیم تمام یا بخشی از عملیات CRUD رو انجام بدیم. یعنی ایجاد، خواندن (بازیابی)، آپدیت و حذف کردن.
و هر منبعی هم با یک URI شناسایی میشه.
مثلا اگر میخوایم روی یک کتاب عملیاتی انجام بدیم، این کتاب بصورت یک منبع تصور میشه که یک URI مختص خودش رو داره.
مثلا URI اون http://example.com/books/book30 هست.
هرچند در سمت سرور از نظر فیزیکی چنین آدرسی میتونه وجود نداشته باشه (که معمولا هم وجود نداره و این آدرسها منطقی هستن و نه فیزیکی) و مثلا تمام کتابها در دیتابیس ذخیره شده باشن (بجای سیستم فایل) و از نظر واقعی هم در نهایت یک اسکریپت واحد ممکنه پاسخ تمام درخواستها رو بده (اما باید توجه داشت که کلاینت نیاز داره تا درخواست خودش رو به URI یکتای اون منبع ارسال کنه و راه دیگری برای مشخص کردن منبع مورد نظر خودش نداره).
اما در معماریهای دیگه، لزومی نداره که همه چیز رو بصورت منبع درنظر بگیریم (البته این فقط یک مفهوم ذهنیه برای درک و باقی موندن در مسیر صحیح معماری مورد نظر) و با URI مشخص کنیم. در معماری های دیگه میتونیم همهء درخواستها رو به یک URI ثابت بفرستیم و چیزی رو که میخوایم لزومی نداره بصورت یک منبع مستقل درنظر بگیریم، بلکه میتونیم صرفا بگیم فلان کتاب رو واکشی کن و تحویل بده یا حذفش کن و غیره.
ولی در REST ما طوری عمل میکنیم که انگار هر موجودیت یک منبع جداگانه است که میشه روش یکسری عملیات پایه رو انجام داد.

خصوصیات دیگری که یک سیستم باید داشته باشه تا بتونه RESTful (یعنی دارای معماری کلی REST) نامیده بشه، بر اساس مقالهء ویکیپدیا ایناست:

- سیستمی با معماری Client–server باشه.
- Stateless باشه. یعنی هیچ اطلاعات وضعیتی راجع به کلاینت روی سرور ذخیره نمیشه که سرور درخواست جاری کلاینت رو با استفاده از اطلاعات ذخیره شده مربوط به درخواستهای قبلی اون کلاینت پاسخ بده. به عبارت دیگر، تمام درخواستها باید مستقل از هم باشن و تمام اطلاعات لازم و مدیریت وضعیت باید در سمت کلاینت ذخیره بشن و اگر این اطلاعات برای پاسخ دادن به درخواست جاری کلاینت لازم هستن باید این اطلاعات در خود درخواست جاری ارسال بشن.
حالا البته این یه تعریف کلی هست که اگر بخوایم وارد جزییات فنیش بشیم شاید دوباره به ابهام و مشکل برخورد کنیم. مثلا آیا اطلاعات سشن که PHP روی سرور ذخیره میکنه تضادی با این تعریف نداره؟ آیا میتونیم از چنین مکانیزمی برای حفظ وضعیت مربوط به درخواستهای REST هم استفاده کنیم؟ اما بهرحال در سیستم سشن PHP هم کوکی سشن باید در سمت کلاینت ذخیره و ارسال بشه، وگرنه سرور به تنهایی و مستقلا عمل ذخیرهء وضعیت و رهگیری کلاینت ها رو انجام نمیده. کلاینت خودش باید توکن سشن رو در هر درخواست ارسال کنه.
- پاسخ های وب سرور در معماری REST باید توسط کلاینت قابل کش شدن باشن. به این منظور در خود پاسخ ها بصورت صریح یا ضمنی مشخص میشه که آیا پاسخ قابل کش شدن هست و تا چه زمانی اعتبار داره.
فکر میکنم برای این امکان از هدرهای کش استاندارد پروتکل HTTP استفاده میشه و نیاز به مکانیزم خارجی و طراحی جدیدی نیست.
در پاسخهای REST که با پروتکل HTTP حمل میشن توسط هدرهای مربوط به کش HTTP مشخص میشه که پاسخ میتونه کش بشه یا نه و تا چه مدتی.
- یک سیستم REST باید قابلیت لایه ای داشته باشه. به این معنا که در مسیر بین کلاینت و سرور، سیستمهای دیگری بتونن بصورت شفاف عمل کنن. بطور مثال یک کلاینت REST که درخواستی رو ارسال میکنه، ممکنه پاسخ رو بجای سرور اصلی از یک کش سرور واسط دریافت بکنه بدون اینکه متوجه این قضیه بشه، یا درخواست/پاسخ در بین راه از یک پراکسی عبور کنه یا یک سرور load-balancing این وسط عمل بکنه بدون اینکه برای درخواست و پاسخ کلاینت و سرور مشکلی پیش بیاد و حتی دو طرف از این قضیه مطلع بشن.
تاجاییکه فهمیدم، یکی از دلایل اینکه REST باید Stateless باشه همینه که سیستم بتونه بصورت چند لایه باشه. چون اگر Stateless نباشه اجرای حالت چند لایه غیرممکن یا حداقل خیلی دشوارتر و پیچیده تر میشه.
- Code on demand هم یک امکان دیگر REST هست که البته آپشناله و نیازی نیست حتما ساپورت بشه. در این رابطه مقالهء ویکیپدیا میگه: «سرورها قادر هستند تا بصورت موقت کارایی های یک کلاینت را با ارسال کد اجرایی، گسترش داده یا سفارشی کنند. مثالهایی از این میتواند شامل کامپوننت های کامپایل شده همچون اپلت های جاوا یا اسکریپت های سمت کلاینت همچون جاوااسکریپت باشد.»
همونطور که میبینید این ویژگی درواقع همون قابلیتی هست که در معماری وب فعلی وجود داره و مرورگرها میتونن از سرورها کد اجرایی کامپایل شده (جاوا، فلش، اکتیوایکس...) یا جاوااسکریپت رو برای اجرای برنامه ای که مد نظر سرور هست دریافت کنن.
- اینترفیس همگانی/یک دست.
منظور از این گزینه هم فکر میکنم همون مفهوم منبع و استفاده از URI باشه برای مشخص کردن هدف، و احتمالا همچنین روشی که سرور منابع و عملیات ممکن روی اونها رو برای کلاینت مشخص میکنه (*).

*: در این مورد از توضیحاتی که آقای Fielding داده اینطور نتیجه گرفتم که یک سیستم REST شباهت زیادی با سایتها/اپلیکیشن ها و صفحات وب عادی داره.
در یک سایت وقتی شما توسط مرورگر خودتون وارد میشید، مرورگر شما از قبل چیزی درمورد منابعی که در اون سایت هست و کارهایی که میشه درش انجام داد نمیدونه. وقتی مرورگر صفحهء اصلی سایت رو باز میکنه کدهای HTML رو دریافت میکنه که در اون منابع مختلف بصورت لینک و عناصر مختلف دارای آدرس منابع در خصیصهء href یا src و امثالهم مشخص شدن و عملیاتی هم که میشه روی اونا انجام داد در خود صفحهء HTML درج شده و قابل انجام هستن. مثلا صفحه یک فرم هم داره که اطلاعاتی رو به فلان آدرس (یک منبع) توسط متد POST ارسال میکنه. این یعنی اینکه شما میتونید با ارسال اطلاعاتی که میخواید (یا بعضی وقتها یکسری اطلاعات فیکس شده در صفحه)، عملیات آپدیت رو روی اون منبع انجام بدید. این خود کلاینت هست که این اطلاعات و نوع داده های منبع و عملیاتی رو که میشه روی هرکدام انجام داد رو تشخیص میده و بعد تصمیم میگیره که در قدم بعدی روی کدام منبع چه عملی انجام بده (حالا این عملیات میتونه انسان هدایت بشه یا توسط یک برنامهء خودکار و با استفاده از AI). مثلا وقتی روی یک لینک کلیک میکنید یعنی عمل بازیابی رو روی منبعی که اون لینک با URL بهش اشاره میکنه انجام میدید و مرورگر شما به وضعیت بعدی منتقل میشه.

اونطور که من متوجه شدم، آقای Fielding میگه که به همین شکل در REST هم اطلاعات مربوط به منابع موجود در سرور و عملیات قابل انجام باید بوسیلهء روش و فرمت مشابهی توسط کلاینت دریافت بشن.

ایشون در بخشی از مقاله ای تحت عنوان API های REST باید بر اساس Hypertext باشند اینطور میگه:


A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]

منبع: http://roy.gbiv.com/untangled/2008/rest-...ext-driven (http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven)

ترجمه: «یک REST API باید بدون اطلاع قبلی ای بیش از URI اولیه و مجموعهء media type های استانداردی که برای مخاطب موردنظر مناسب/مرتبط هستند (م: تاجاییکه فهمیدم منظور از media type در اینجا همون MIME type هست) بتواند ورود شود. از آن نقطه به بعد، تمام انتقال وضعیت اپلیکیشن باید بوسیلهء انتخاب کلاینت از میان انتخابهایی که سرور در اطلاعات دریافت شده در اختیار گذاشته است و یا بصورت ضمنی بوسیلهء دستکاری کاربر در آن اطلاعات مشخص میشود، هدایت شود. تغییرات وضعیت میتوانند بوسیلهء آگاهی کلاینت از نوع رسانه ها (media type) و مکانیزمهای ارتباطی منبع تعیین (یا محدود) شوند، که هردوی اینها میتواند بصورت on-the-fly ارتقا داده شود (بطور مثال code-on-demand). [قصور در این مورد به معنای آنست که اطلاعات خارج از کانال اصلی، بجای hypertext، در حال هدایت تراکنش است]»

همونطور که میبینید ایشون میگن که در REST برنامه ابتدا وارد یک نقطهء ورود اولیه/اصلی میشه (مثل صفحهء اول یک وبسایت) و بعد از اون فقط با اطلاعاتی که خود سرور بصورت ابرمتن ارسال کرده میفهمه و تصمیم میگیره که چه منابع و عملیاتی در وضعیت فعلی در دسترس هستن و وضعیت بعدی رو از بین اونها انتخاب میکنه (مثل پر کردن و ارسال یک فرم، بازیابی (باز کردن) یک لینک جدید، ...).

راستی بعنوان تکمیل مطلب اضافه کنم که در REST میان و متدهای HTTP رو به عملیات مورد نظر نگاشت میکنن. یعنی وقتی میخوان یک منبع رو حذف کنن (خود منبع که با URI مشخص میشه)، درخواست رو با HTTP DELETE ارسال میکنن، وقتی میخوان بهش چیزی اضافه کنن از متد POST استفاده میکنن (آپدیت)، وقتی میخوان بازیابی کنن درخواست رو با متد GET ارسال میکنن، وقتی میخوان منبعی رو ایجاد/Overwrite کنن از PUT استفاده میکنن. اما این قضیه اجباری نیست و جاهای دیگر بنا به محدودیت ها یا ترجیح طراح میشه از مکانیزمهای دیگری برای مشخص کردن نوع عملیات CRUD استفاده کرد. مثلا با پارامتر URI هم میشه نوع عملیات رو مشخص کرد.

و در پایان گفتاری از Roy T. Fielding:


To some extent, people get REST wrong because I failed to include enough detail on media type design within my dissertation. That’s because I ran out of time, not because I thought it was any less important than the other aspects of REST. Likewise, I suspect a lot of people get it wrong because they read only the Wikipedia entry on the subject, which is not based on authoritative sources.

However, I think most people just make the mistake that it should be simple to design simple things. In reality, the effort required to design something is inversely proportional to the simplicity of the result. As architectural styles go, REST is very simple.

ترجمه: «تاحدی مردم REST را اشتباه میفهمند چون من نتوانستم جزییات کافی درمورد طراحی نوع رسانه (media type) در تز خودم شامل کنم. آن به این خاطر بود که وقت من کم آمد، نه بخاطر آنکه فکر کردم آن از بقیهء جوانب REST کم اهمیت تر است. همچنین، من حدس میزنم که عدهء زیادی از افراد آنرا اشتباه میفهمند چون آنها فقط مقالهء ویکیپدیا درمورد موضوع را میخوانند که بر اساس منابع معتبر نیست.

اما، من فکر میکنم بیشتر مردم به سادگی مرتکب این اشتباه میشوند که فکر میکنند طراحی چیزهای ساده باید ساده باشد. در واقعیت، تلاش لازم برای طراحی یک چیز، با سادگی نتیجهء آن رابطهء معکوس دارد. از نظر شیوه های معماری، REST بسیار ساده است.»

[eshpilen]

منابع خوبی درمورد REST:

http://rest.elkstein.org/

دقت کنید که این مقاله یک صفحه نیست و بقیش رو میتونید با کلیک روی لینک Continues در پایین صفحه دنبال کنید.

این بصورت تصویری و با تشبیه و با حجم نسبتا کم، حداقل بخشی از ساختار و مزایای REST رو توصیف کرده: http://www.slideshare.net/trilancer/rest...ce-1421793 (http://www.slideshare.net/trilancer/restful-user-experience-1421793)

این یکی تماما متن است و حجمش هم نسبتا زیاده، ولی بنظر بنده از نظر فنی و دقت و کامل بودن بسیار غنی تر از منبع قبلی هست و بخصوص اگر با مطالعات و زمینهء کافی بخونیدش، خیلی مفاهیم رو روشن و مطمئن میکنه و در نتیجه بینش خوبی رو ایجاد میکنه: http://www.slideshare.net/ksumit/restful-webservices

[eshpilen]

REST درواقع کوششی در بسط دادن ساختار موفق وب، به پدیده های جدید مثل وبسرویس است.
به این صورت بازدهی بالا میره و از دوباره کاری اجتناب میشه و از معماری هایی که انعطاف کمتری دارن اجتناب میشه.
میگن بزرگترین سیستم RESTful وب است.

درمورد پروتکل ها/استانداردهایی مثل SOAP باید بگم خیلی ها اعتقاد دارن که طراحان اینها دچار اشتباهات اساسی شدن و هم یک چیزی بیش از حد پیچیده رو ایجاد کردن و هم چرخ رو دوباره اختراع کرد و هم این سیستم در طولانی مدت انعطاف کافی نداره یا حداقل بهینه نیست؛ ضمن اینکه با بقیهء اجزاء و معماری وب به خوبی هماهنگ نمیشه.
گفته میشه یک علت اینه که طراحان SOAP خودشون عملا برنامه نویس و توسعه دهنده نبودن.

راستی درسته در ابتدا گفتیم REST و SOAP از یک جنس نیستن که با هم مقایسه بشن، ولی این بیشتر از نظر دقت تعریف تئوریک هست. در عمل چون طبیعی ترین پیاده سازی معماری REST در وب سرویس هاست، بنابراین میتونیم REST و SOAP رو بعنوان دو معماری وب سرویس با هم مقایسه کنیم و این مقایسهء معنی دار و مفیدی هست. اما باید در عین حال تعریف دقیق و تفاوت ماهیتی هرکدام از اینها به تنهایی رو هم دونست.