قبل از اینکه به توضیح این قسمت بپردازم لازم میدونم که دو مفهوم رو توضیح بدم : Loosely Coupled و Tightly Coupled

تفاوت Loosely Coupled و Tightly Coupled

1- Loosely-Coupled به معنای اتصال و وابستگی ضعیف دلالت دارد. یعنی Client به Server وابستگی ضعیفی دارد و با حداقل دانش از نیازمندی های سرور میتواند با سرور کار کند. (در ادامه مثال را بررسی کنید.)

2- Tightly-Coupled به معنای اتصال و وابستگی قوی میباشد. و کلاینت جهت کار با سرور باید اطلاعات زیادی از سرور داشته باشد.

یک مثال ساده در دنیای واقعی از اتصال ضعیف رو میتونید در مادربرد تصور کنید، که شکاف های اتصال RAM به صورت Loosely Coupled تعبیه شده است و کاربر به راحتی میتواند RAM مادربرد خود را تعویض کند اما مثلا خازن ها به صورت اتصال قوی یا همان Tightly Coupled طراحی شده است و کاربر نهایی به راحتی نمیتوان آن ها را تعویض کند.

حال فرض کنید اگر تمامی قطعات در مادربرد به صورت اتصال قوی ساخته میشد برای تعویض RAM,CPU,Graphic Card و سایر قطعات میبایست کل مادربرد تعویض گردد.

هدف ساختن وب سرویس های RESTful این است که مطمئن باشیم کنترلر های Web API و Client به صورت Loosely Coupled طراحی شوند.

با یک مثال ساده این مدل را توضیح میدهم:

فرض کنید یک Web API Controller برای محصولاتمان با نام ProductsController داریم. اگر در این کنترلر چهار عمل اصلی GET - POST - PUT - DELETE را داشته باشم به طوری که به ازای هرکدام از این موارد یک متد متناظر با آن را بسازیم مثلا برای GET داشته باشم GETProduct و برای POST داشته باشم POSTProduct آنگاه برای استفاده از تمامی این متدها کافیست از URI زیر استفاده کنیم:

/api/Products

اگر از url مثلا mysite.com/api/products استفاده کنم سیستم روتینگ Web API اتوماتیک تشخیص میدهد که این یک دستور GET است و آن را به متد GET مورد نظر MAP میکند. برای POST و غیره هم همینطور پس در اینجا مشاهده میکنیم کلاینت با حداقل دانش درباره سرور و متدهای سرور به راحتی میتواند با سرور کار کند.

اما اگر بخواهم در یک کنترلر چندین متد مختلف قراردهم که همگی از نوع GET باشند مثلا لیست کالاها، لیست مشتریان، لیست خریدها آنگاه نیاز است که به ازای تمامی این متدها uri مورد نظر را نیز به کلاینت بدهم پس کلاینت عملا اتصال قوی پیدا میکند و نیاز دارد آدرس های زیر را داشته باشد: (به این مدل، مدل non-REST میگویند)

/api/MyController/Products
/api/MyController/Customers
/api/MyController/Orders

این درحالی است که در مثال قبلی ما نیازی به دانستن نام اکشن نداشتیم.

مدل RESTful در عمل نگهداری کدها و توسعه را راحت تر کرده و به ازای تغییرات نیازی نیست که تمام مشتریان را در جریان قرار دهیم.


وب سرویس های RESTful

چه چیزهایی هستند؟

وب سرویس های RESTful مناسب برای جداسازی کلاینت ها از وب سرویسها هستند. نیازمند زمان بیشتری در طراحی و کدنویسی میباشند اما نگهداری آنها ساده تر است.

چه موقعی از آنها استفاده کنیم؟

مواقعی که Client ما قرار است توسط سایر توسعه دهندگان نیز استفاده شود (شخص ثالث)(Third-Party) و یا مواقعی که انتظار تغییرات زیاد در API را داریم از وب سرویس های RESTful استفاده میکنیم.

چه چیزهایی نیاز است که بدانیم؟

شما انتخاب های مختلفی در نحوه ساخت سرویسهای RESTful دارید که در نتیجه میتوان گفت : چگونه میخواهید ارتباط کلاینت و سرور را به صورت Loosely Coupled طراحی کنید.

هر چه دانش قبلی کلاینت برای استفاده از وب سرویس کمتر باشد، سرویس شما بیشتر به مدل RESTful نزدیک است.