RESTful API چیست؟ معرفی جامع به زبان ساده

برای اینکه موضوع اصلی این مقاله رو درک کنید نیازه که با مفاهیم API و Web service آشنا باشید که در ادامه گفته شده:

Application Programming Interface به اختصار API در واقع یک رابط بین سیستم های نرم افزاری است که ارتباط برقرار کردن بین سیستم های مختلف رو ممکن میکنه. API یک نوع رابط نرم افزاری است که به برنامه ها امکان استفاده از خدمات سایر نرم افزارها رو میده برای آشنایی بیشتر با API میتونید مقاله API چیست رو مطالعه کنید.

اگر API در بستر یک سرویس تحت وب ارائه بشه و ارتباط برقرار کردن بین سرویس های مختلف رو از طریق شبکه اینترنت ممکن کنه بهش Web API یا Web Service (وب سرویس) میگن. 

رویکرد های مختلفی برای توسعه API ها در وب سرویس ها بکار میره مثل SOAP ، gRPCT، GraphQL ، PRC که یکی از شناخته شده ترین اون ها REST است.

REST یا REpresentational State Transfer نه یک پروتکل است نه یک استاندارد، بلکه یک سبک معماری است و مجموعه ای از محدودیت های معماری است که برای توسعه API ها به کار میره و توسعه دهنده های API میتونن به روش های مختلف از اون استفاده کنن.

همون طور که گفته شد REST یک سبک معماری برای توسعه API است ولی مفهموم RESTful یا رست فول به اون وب سرویسی گفته میشه که سبک معماری REST روی اون پیاده سازی شده.

پس به زبان ساده اگر توی توسعه API از یکسری قوانین پیروی کنیم به راحتی میتونیم برچسب RESTful رو روی اون وب سرویس بزنیم.

RESTful یا رست فول در واقع یکی از انواع معماری های طراحی API است که از سبک معماری REST پیروی میکنه و به شدت مبتنی بر پروتکل HTTP است (البته محدود به این پروتکل نیستیم). پیروی از این مجموعه قوانین باعث میشه وب سرویس هایی سریع و قابل اعتماد و توسعه پذیر ساخت.

تحلیل کلمه RESTیا REpresentational State Transfer:

• -REpresentational: این اصطلاح به اون فرمت دیتای برگشتی اشاره دارد یا به اصطلاح (ظاهر) دیتای برگشتی اشاره داره. REST API فرمت های مختلفی مثل JSON، XML، HTML رو ساپورت میکنه (برخلاف SOAP که فقط از فرمت XML پشتیبانی میکنه) که البته محبوب ترینش JSON است.
  این طوری توسعه دهنده میتونه از بین فرمت های مختلف اونی که هم برای سمت Client و هم برای داده های سمت سرور (Server-Side) مناسب باشه رو انتخاب کنه. به همین دلیله که معماری REST یک معماری انعطاف پذیره چون دست توسعه دهنده رو باز میزاره.
• -State Transfer: به ماهیت Stateless این معماری اشاره دارد. Stateless بودن به این معنی نیست که اطلاعت وضعیت ذخیره نمیشن بلکه به این معنی است که اطلاعت وضعیت در جایی غیر از سرور ذخیره میشن.
  این طوری هیچ اطاعات وضیتی در سمت سرور ذخیره نمیشه و هر درخواست حاوی تمامی اطلاعت لازم برای درک سرور است (به عبارتی هر درخواست مستقل از درخواست دیگر است).

به طور کلی برای توسعه وب سرویس با معماری RESTful باید شش اصول یا قانون رو رعایت کرد که در ادامه باهاشون آشنا میشیم:

وقتی شما یک API با معماری RESTful میسازید یکپارچگی اون در طول توسعه یک اجبار است و برای اینکه این یکپارچگی حفظ بشه شما باید یکسری اصول ثابت رو در طول توسعه رعایت کنید که شامل چهار مورد زیر هستند:

• 1. شناسایی منابع: هر منبع (Resource) باید یک آدرس منحصر به فرد داشته باشد که میتواند URI یا URL باشه.
• 2. متد های استاندارد: Client برای ارتباط برقرار کردن با سرور باید از متد های استاندارد پروتکل HTTP استفاده کنه. متد های HTTP برای انجام عملیات روی منابع مثل GET، POST، PUT، DELETE هستن.
• 3. Self-descriptive messages: اون جواب یا Response ای که Client از سمت سرور گرفته باید انقدری شفاف و واضح باشه که Client بدون هیچ مستندات اضافی اون رو درک کنه.
  یکی از این اطلاعات که Client باید با استفاده از اون پاسخ سرور رو درک کنه status code ها یا کد های وضعیت هستن که در ادامه بیشتر بررسیش مکنیم.
• 4. HATEOAS: که مخفف شده Hypermedia as the engine of application state است. منظور از HATEOAS این است که در پاسخ (Response) سرور حاوی لینک های مرتبط با منابع (Resource) باشه، به عنوان مثال لینک مربوط به نظرات کاربران یا لینک مقالات مرتبط که توسعه دهنده سمت Client میتونه بر اساس نیاز اون ها رو استفاده کنه.

شاید در نگاه اول Uniform Interface پیچیده به نطر برسه ولی ساده تر از چیزیه که به نظر میرسه کافیه اون API ای که با معماری RESTful توسعه داده شده چهار ویژگی بالا رو داشته باشه تا اصل Uniform Interface رعایت بشه.

توی این معماری حداقل وابستگی بین Client یا Front-End و سمت سرور یا Back-End وجود داره و از همدیگه کاملا مجزا هستن. این ویژگی یک مزیت خیلی بزرگه چون میشه از دیتای سمت سرور رو توی Client های مختلف مثل وب و موبایل و دسکتاپ و.. استفاده کرد و هر تیم توسعه میتونه به صورت مجزا و بدون وابستگی روی توسعه اپلیکیشن ها تمرکز کنن.

اون Response های ارسالی که سرور به Client میفرسته باید قابلیت Cashe شدن در سمت سرور رو داشته باشن (دلیل این کار برای بهبود کارایی و performance است).

همون طور که بالاتر اشاره کردم  Stateless بودن به این معنی نیست که اطلاعت وضعیت ذخیره نمیشن بلکه به این معنی است که اطلاعت وضعیت در جایی غیر از سرور ذخیره میشن و هر درخواست باید حاوی تمامی اطلاعت لازم برای درک سرور باشه.

این مسئله باعث میشه که هر درخواست از درخواست دیگه مجزا باشه چون همه اطلاعات مورد نیاز برای پردازش توی همون درخواست وجود داره و کلا سرور نسبت به وضعیت درخواست های قبلی Client اطلاعی نداره.

مزیتی که Statelessبودن به وجود میاره اینه که دیگه با تغییرات سمت سرور، Client ما به مشکل بر نمیخوره.

توی معماری RESTful API به عنوان مثال میتونه لایه های سیستم به شکل زیر باشه:

• -لایه نمایش: که مسئول ارائه رابط کاربری برای ارتباط برقرار کردن کاربر با سیستم است
• -لایه منطق کسب و کار (Business Logic): مسئول عملیات اصلی سیستم است
• -لایه دسترسی به داده:مسئول ارتباط با دیتابیس و سایر منابع داده ای است 

لایه بندی شدن برنامه مزیت های خیلی زیادی داره مثل:

• 1. افزایش قابلیت نگهداری: تغییر در یک لایه روی همه لایه ها تاثیر نمیزاره (هر چند میتونه به لایه های مجاور تاثیر بزاره)
• 2. افزایش انعطاف پذیری: هر لایه میتونه بصورت مستقل توسعه داده بشه 
• 3. تسهیل توسعه: تیم های توسعه مختلف میتونن روی لایه های مختلف به صورت موازی کار کنن در نتیجه سرعت توسعه بصورت چشمگیری بالا میره
• 4. تسهیل تست: میشه هر لایه رو بصورت مجزا تست و خطایابی کرد
• 5. افزایش امنیت: با جدا کردن لایه های مختلف میشه سطح دسترسی به هر لایه رو محدود کرد

منظور از Code on Demand این است به جای اینکه داده را بصورت خام از سرور به Client ارسال کنیم میتونیم بخشی از کد رو ارسال کنیم. حالا این کد ارسالی میتونه یک اسکریپت کوچیک یا حتی یک ماژول کامل باشه.

این اصل برخلاف 5 اصل دیگه که توضیح دادیم اختیاری است و توی بکارگیری اون باید خیلی دقت کرد چون میتونه مشکلات امنیتی جدی به وجود بیاره.

Status Code یا کد وضعیت HTTP که سرور برای پاسخ به Client ارسال میکنه که شامل اعداد سه رقمی هستن. درسته که Status Code های زیادی داریم ولی با یک نگاه به ساختار عدد میشه تشخیص داد که توی کدوم دسته قرار میگیره که به شکل زیر است:

• -1xx اطلاعاتی (informational): یعنی سرور درخواست را دریافت کرده و درحال پردازش است.
• -2xx موفقیت آمیز (success): یعنی درخواست موفقیت آمیز بوده و Client اطلاعات مدنطر رو دریافت کرده.
• -3xx تغییر مسیر (redirection): یعنی شما ریدایرکت شده اید و برای تکمیل درخواست به فعالیت بیشتری نیاز دارید.
• -4xx خطای کاربر (client error): یعنی دسترسی به وبسایت یا صفحه ممکن نیست. ممکنه درخواست به نحو نامناسبی صورت گرفته باشه یا کلا صفحه قابل دسترس نباشه.
• -5xx خطای سرور (server error): یعنی با این وجود که درخواست معتبر به نظر میرسه، سرور قادر به اجرای اون نیست (مشکل از سمت سرور است).

CRUD که مخفف Create، Read، Update، Delete است و به چهار عمل اصلی اشاره دارد که روی داده ها انجام میشه و برای انجام این عملیات ها نیازه که با HTTP Verb ها یا همون متد های HTTP آشنا بشیم:

• -GET: به منظور فراخوانی منابع
• -POST: متدی برای ایجاد منبع جدید
• -PUT: متدی برای آپدیت و ایجاد تغییر روی منابعی که از قبل ثبت شدن
• -DELETE: متدی برای حذف منبع

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

متد GET که از پرکاربرد ترین متد ها است. فرض کنید در طی درخواستی به سرور میخوایم لیستی از مقالات رو از سرور دریافت کنیم:

GET /api/blog/articles

نکته: توافقی وجود داره که وقتی همه منابع (همون لیست یا تعدادی از منابع) رو فراخوانی مکنیم باید اسم اون منبع (Resource) رو به صورت جمع (plural) بنویسیم مثل اینجا articles به صورت جمع آورده شده. 

پاسخ یا Response ای که سرور طی درخواست بالا برمیگردونه به صورت لیستی از داده است به طور مثال به شکل زیر است:

[
    {
        "id": 1,
        "title": "title 1",
        "slug": "slug-1",
        "author": "author 1"
    },
    {
        "id": 2,
        "title": "title 2",
        "slug": "slug-2",
        "author": "author 2"
    },
    {
        "id": 3,
        "title": "title 3",
        "slug": "slug-3",
        "author": "author 3"
    }
]

حالا اگه بخوایم فقط یکی از داده های بالا رو با متد GET دریافت کنیم مثل قبل عمل میکنیم با این تفاوت که در آخر اون شناسه (که اینجا id اون مقاله است) رو در آخر میاریم:

GET /api/blog/articles/1

 حالا در پاسخ سرور به ما اون یک منبع بخصوص رو به جای کل داده ها به ما برمیگردونه:

[
    {
        "id": 1,
        "title": "title 1",
        "slug": "slug-1",
        "author": "author 1"
    }
]

نکته: به URL هایی که درخواست دادیم به اصطلاح Endpoint میگن که اجازه تعامل توسعه دهنده با وب سرویس رو میده.

اکثر فرم هایی که در وبسایت ها میبینید مثل فرم ثبت نام یا فرم ثبت نظر جدید از جاهایی است که متد POST کاربرد داره مثل:

POST /api/blog/articles
[
    {
        "id": 4,
        "title": "title 4",
        "slug": "slug-4",
        "author": "author 4"
    }
]

نکته: در صورت موفقیت آمیز بودن Status Code که برمیگردونه 201 است که به معنی Created است.

این متد برای آپدیت به کار میره به عنوان مثال اگه بخوایم title و slug مقاله رو عوض کنیم بدین شکل میشه با استفاده از شناسه (اینجا id مقاله است) به اون منبع بخصوص درخواست میفرستیم:

PUT /api/blog/articles/1
[
    {
        "title": "new title 1",
        "slug": "new-slug-1",
    }
]

نکته: در صورت موفقیت آمیز بودن درخواست کد وضعیت 200 به معنی OK رو برمیگردونه.

اینجا هم با استفاده از شناسه (اینجا id مقاله است) به اون منبع بخصوص برای حذف کردنش درخواست ارسال میکنیم:

DELETE /api/blog/articles/1

نکته: در صورت موفقیت آمیز بودن کد وضعیت 204 به معنی No Content رو برمیگردونه و اگر بیشتر از یکبار درخواست DELETE رو ارسال کنید کد وضعیت 404 میگیرید که به معنی Not Found است چون منبعی با این شناسه طی درخواست قبلی حذف شده و دیگه وجود نداره که بخواید به این شناسه درخواست بفرستید.

نکته: طی درخواست های که انجام دادیم شاید متوجه این شده باشید که بعضی Endpoint هایی که درخواست دادیم یکسان بودند و فقط متد اون فرق میکرد این یک مشکل نیست چون سمت سرور بر اساس متدی که درخواست دادید میتونه تسک بخصوصی رو انجام بده.

متد GET علاوه بر اینکه رایج ترین نوع متد HTTP است، متد امنی هم محسوب میشه چون این متد فقط یکسری دیتا رو از سرور دریافت میکنه و تغییری روی دیتاهای سرور نمیتونه انجام بده.

توی توسعه RESTful API اگر یک درخواست از جنس HTTP چندین بار پشت سر هم تکرار بشه و نتیجه همه اون ها یکی باشه و تاثیر یکسانی با همون درخواست اول داشته باشه میگیم که اون سرویس Idempotentاست.

غیر از متد POST، بقیه متد هایی که اشاره کردیم Idempotent هستن چون مثلا متد GET چندین بار هم تکرار بشه بازم همون نتیجه اول رو میده ولی متد POST هر بار منبع جدیدی رو به سرور اضافه میکنه.

توی این مقاله به صورت جامع RESTful API رو به زبان ساده معرفی کردیم ولی این نکته رو دقت کنید که همه RESTful API ها یک Web API هستن ولی همه Web API ها RESTful API نیستن چون Web API هایی وجود دارن که معماری غیر از REST دارن.

اگه شما با پایتون(python) آشنایی دارید و میدونید که پایتون چیست (اگه با پایتون آشنایی ندارید میتونید دوره آموزش پایتون رو بصورت رایگان شرکت کنید) و توسعه دهنده جنگو (Django) هستید (اگر آشنایی ندارید میتونید مقاله جنگو چیست رو بخونید) با استفاده از DRF میتونید RESTful API های سریع و استاندارد بسازید و اگر نمی دونید که DRF چیه کافیه مقاله DRF چیست رو مطالعه کنید.