REST چیست؟ راهنمای کامل اصول، مفاهیم و نحوه پیاده‌سازی

نسرین شریفی
۲۹ بهمن ۱۴۰۳

فرض کنید وارد یک رستوران شده‌اید، منو را نگاه می‌کنید، غذای مورد نظرتان را انتخاب می‌کنید و سفارش می‌دهید. گارسون بدون دانستن تاریخچه سفارش‌های قبلی شما، غذا را برایتان می‌آورد. این دقیقا مشابه روشی است که REST کار می‌کند.

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

در ادامه خواهید خواند:

• REST چیست؟
• ارتباط بین کلاینت و سرور
• تمرین با REST
• مدل ها
• درخواست ها و پاسخ ها
• سوالات متداول
• جمع بندی

REST چیست؟

REST یا انتقال وضعیت نمایشی، یک سبک معماری است که استانداردهایی را برای ارتباط بین سیستم‌های کامپیوتری در وب فراهم می‌کند و این ارتباط را آسان‌تر می‌سازد. سیستم‌هایی که از REST پیروی می‌کنند، اغلب به آن‌ها سیستم‌های RESTful گفته می‌شود، با ویژگی هایی مانند بی‌حالتی (Statelessness) و جداسازی وظایف کلاینت و سرور شناخته می‌شوند. توجه داشته باشید که اگر به دنبال یک شغل در حوزه فناوری هستید، ممکن است در یک مصاحبه از شما بخواهند که REST را تعریف کنید.

جداسازی کلاینت و سرور

در معماری REST، پیاده سازی کلاینت و سرور می‌توانید به صورت مستقل از هم انجام شود، بدون اینکه هیچ کدام از دیگری اطلاعی داشته باشد. این به این معناست که کدهای سمت کلاینت می‌توانند در هر زمانی تغییر کنند، بدون اینکه بر عملکرد سرور تاثیر بگذارند، و بالعکس، سرور نیز می‌تواند بدون تاثیر گذاری بر کلاینت، تغییر یابد.

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

با استفاده از یک رابط REST، کلاینت‌های مختلف می‌توانند به همان نقاط پایانی (Endpoints) REST متصل شوند، همان اقدامات را انجام دهند و پاسخ‌های یکسانی دریافت کنند.

بی حالتی (Statelessness)

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

این محدودیت بی‌حالتی از طریق استفاده از منابع به جای دستورات اعمال می‌شود. منابع همان نام‌ها (اسامی) در وب هستند؛ آن‌ها هر شی سند یا اطلاعاتی را توصیف می‌کنند که ممکن است نیاز به ذخیره یا ارسال به سایر سرویس ها داشته‌ باشد.

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

بیشتر بخوانید: API چیست؟

ارتباط بین کلاینت و سرور

در معماری REST، کلاینت‌ها درخواست‌هایی را برای دریافت یا تغییر منابع ارسال می‌کنند و سرورها به این درخواست‌ها پاسخ می‌دهند. در ادامه روش های استاندارد برای ارسال درخواست ها و دریافت پاسخ بررسی شده‌است.

ارسال درخواست ها

REST مستلزم آن است که کلاینت برای دریافت یا تغییر داده‌ها در سرور، درخواست ارسال کند. یک درخواست معمولا شامل موارد زیر است.

• یک فعل HTTP که مشخص می‌کند چه عملیاتی باید انجام شود.
• یک هدر که به کلاینت اجازه می‌دهد اطلاعاتی درباره درخواست ها ارسال کند.
• یک مسیر برای دسترسی به منبع مورد نظر.
• یک بدنه اختیاری که ممکن است داده‌هایی را شامل شود.

افعال HTTP

در سیستم REST، چهار فعل اصلی HTTP برای تعامل با منابع استفاده می‌شود:

• GET: دریافت یک منبع خاص یا مجموعه‌ای از منابع.
• POST: ایجاد یک منبع جدید.
• PUT: به‌روزرسانی یک منبع خاص (با شناسه).
• DELETE: حذف یک منبع خاص (با شناسه).

هدرها و پارامترهای Accept

در هدر درخواست، کلاینت نوع محتوایی را که قادر به دریافت آن از سرور است ارسال می‌کند. این فیلد Accept نام دارد و اطمینان حاصل می‌کند که سرور داده‌هایی را ارسال نکند که کلاینت قادر به درک یا پردازش آن ها نیست. گزینه‌های موبوز به انواع محتوا، MIME Type (یا Multipurpose Internet Mail Extensions) نام دارد که می‌تواند اطلاعات بیشتری درباره آن‌ها را در MDN Web Docs مطالعه کنید.

MIME Type گه برای تعیین نوع محتوا در فیلد Accept استفاده می‌شوند، شامل یک نوع و یم زیر نوع هستند که با یک اسلش (/) از هم جدا می‌شوند.

برای مثال، اگر یک فایل متنی شامل HTML باشد، نوع آن text/html خواهد بود. در صورتی که این فایل CSS داشته باشد، مقدار آن text/css تعیین می‌شود. همچنین، یک فایل متنی ساده بدون فرمت خاص، به‌صورت text/plain مشخص می‌شود. با این حال، text/plain به این معنا نیست که هر نوع محتوای متنی را می‌توان به این فرمت ارسال کرد. برای مثال، اگر کلاینت انتظار دریافت text/css را داشته باشد اما به‌جای آن text/plain دریافت کند، نمی‌تواند محتوا را به درستی تشخیص دهد.

سایر انواع و زیرگونه‌های رایج:

• تصویر:image/png، image/jpeg، image/gif
• صوت:audio/wav، audio/mpeg
• ویدئو:video/mp4، video/ogg
• اپلیکیشن:application/json، application/pdf، application/xml، application/octet-stream

برای مثال، اگر کلاینت بخواهد به یک منبع با شناسه ۲۳ در مجموعه مقالات یک سرور دسترسی پیدا کند، ممکن است درخواست زیر را ارسال کند:

GET /articles/23  
Accept: text/html, application/xhtml

در این درخواست، فیلد Accept مشخص می‌کند که کلاینت محتوا را در قالب text/html یا application/xhtml خواهد پذیرفت.

مسیر ها

درخواست‌ها باید شامل مسیری به یک منبع باشند که عملیات موردنظر روی آن انجام شود. در APIهای RESTful، مسیرها باید به گونه‌ای طراحی شوند که به کلاینت کمک کنند بفهمد چه اتفاقی در حال رخ دادن است.

به‌طور معمول، بخش اول مسیر باید شکل جمع منبع موردنظر باشد. این روش باعث می‌شود که مسیرهای تو در تو ساده‌تر خوانده و درک شوند.

به‌عنوان مثال، مسیری مانند:

fashionboutique.com/customers/223/orders/12

حتی اگر برای اولین بار با آن روبه‌رو شوید، کاملاً مشخص است که به چه چیزی اشاره دارد. زیرا این مسیر سلسله‌مراتبی و توصیفی است. در اینجا، مشخص است که در حال دسترسی به سفارشی با شناسه 12 برای مشتری با شناسه 223 هستیم.

مسیرها باید اطلاعات کافی برای شناسایی یک منبع را با سطح مشخصی از جزئیات داشته باشند. هنگام ارجاع به فهرستی از منابع، معمولاً نیازی به افزودن یک شناسه نیست.

برای مثال، در یک درخواست POST به مسیر:

fashionboutique.com/customers

نیازی به افزودن شناسه نیست، زیرا سرور خودش یک شناسه جدید برای شیء ایجاد خواهد کرد.

اما اگر بخواهیم به یک منبع خاص دسترسی داشته باشیم، باید شناسه آن را به مسیر اضافه کنیم.

برای مثال:

GET fashionboutique.com/customers/:id

آیتمی را که دارای شناسه مشخص‌شده در منبع customers است، بازیابی می‌کند.

DELETE fashionboutique.com/customers/:id

آیتمی را که دارای شناسه مشخص‌شده در منبع customers است، حذف می‌کند.

ارسال پاسخ ها

زمانی که یک کلاینت درخواستی به سرور ارسال می‌کند، سرور باید پاسخی متناسب با آن ارسال کند. این پاسخ شامل داده‌های موردنظر، نوع محتوا و یک کد وضعیت (Status Code) برای مشخص کردن موفقیت یا عدم موفقیت عملیات خواهد بود.

انواع محتوا (Content Types)

زمانی که سرور داده‌ای را برای کلاینت ارسال می‌کند، باید در هدر پاسخ (Response Header) نوع محتوا (Content-Type) را مشخص کند. این فیلد در هدر پاسخ، نوع داده‌ای را که در بدنه‌ی پاسخ ارسال می‌شود، به کلاینت اعلام می‌کند. این انواع محتوا همان MIME Types هستند که در فیلد Accept هدر درخواست نیز استفاده می‌شوند.

نوع محتوایی که سرور در پاسخ ارسال می‌کند باید یکی از گزینه‌هایی باشد که کلاینت در فیلد Accept درخواست مشخص کرده است.

به‌عنوان مثال، زمانی که کلاینت برای دریافت یک منبع با شناسه ۲۳ در مجموعه‌ی articles، این درخواست GET را ارسال می‌کند:

GET /articles/23 HTTP/1.1  
Accept: text/html, application/xhtml  

سرور ممکن است پاسخ را با این هدر ارسال کند:

HTTP/1.1 200 (OK)  
Content-Type: text/html  

این پاسخ نشان می‌دهد که محتوای درخواستی در بدنه‌ی پاسخ ارسال شده و نوع آن text/html است که کلاینت اعلام کرده بود که می‌تواند آن را دریافت کند.

کدهای پاسخ (Response Codes)

پاسخ‌های سرور شامل کدهای وضعیت (Status Codes) هستند که اطلاعاتی درباره‌ی موفقیت یا شکست عملیات به کلاینت می‌دهند.
به‌عنوان یک توسعه‌دهنده، نیازی نیست که همه‌ی کدهای وضعیت را بدانید، اما باید رایج‌ترین آن‌ها و نحوه‌ی استفاده از آن‌ها را بشناسید:

برای هر متد HTTP، کدهای وضعیت مورد انتظار در صورت موفقیت درخواست به این شکل خواهد بود:

• GET → ۲۰۰ (OK)
• POST → ۲۰۱ (CREATED)
• PUT → ۲۰۰ (OK)
• DELETE → ۲۰۴ (NO CONTENT)
• در صورت ناموفق بودن عملیات، سرور باید دقیق‌ترین کد وضعیت ممکن را متناسب با مشکل رخ داده برگرداند.

نمونه‌هایی از درخواست و پاسخ

فرض کنید یک برنامه داریم که امکان مشاهده، ایجاد، ویرایش و حذف مشتریان و سفارشات را در یک فروشگاه لباس فراهم می‌کند و این برنامه روی fashionboutique.com میزبانی شده است. می‌توانیم یک API مبتنی بر HTTP برای انجام این عملیات ایجاد کنیم:

مشاهده‌ی همه‌ی مشتریان

درخواست:

GET http://fashionboutique.com/customers  
Accept: application/json  

پاسخ ممکن:

Status Code: 200 (OK)  
Content-type: application/json  

سپس داده‌های مشتریان در قالب application/json در بدنه‌ی پاسخ ارسال خواهد شد.

ایجاد یک مشتری جدید

درخواست:

POST http://fashionboutique.com/customers  
Body:
{
  "customer": {
    "name": "Scylla Buss",
    "email": "scylla.buss@codecademy.org"
  }
}

سرور یک شناسه برای این شیء ایجاد کرده و با هدر زیر به کلاینت برمی‌گرداند:

201 (CREATED)  
Content-type: application/json  

مشاهده‌ی یک مشتری خاص

درخواست:

GET http://fashionboutique.com/customers/123  
Accept: application/json 

پاسخ ممکن:

Status Code: 200 (OK)  
Content-type: application/json  

سپس داده‌های مشتری با شناسه‌ی ۱۲۳ در قالب application/json در بدنه‌ی پاسخ ارسال خواهد شد.

به‌روزرسانی اطلاعات یک مشتری

درخواست:

PUT http://fashionboutique.com/customers/123  
Body:
{
  "customer": {
    "name": "Scylla Buss",
    "email": "scyllabuss1@codecademy.com"
  }
}

پاسخ ممکن:

Status Code: 200 (OK)  

این پاسخ نشان می‌دهد که اطلاعات مشتری با شناسه‌ی ۱۲۳ با موفقیت تغییر کرده است.

حذف یک مشتری

درخواست:

DELETE http://fashionboutique.com/customers/123  

پاسخ ممکن:

Status Code: 204 (NO CONTENT)  

این پاسخ نشان می‌دهد که مشتری با شناسه‌ی ۱۲۳ حذف شده است و هیچ داده‌ای در بدنه‌ی پاسخ ارسال نمی‌شود.

همچنین بخوانید: نحوه ایجاد یک API REST با Flask در سرور مجازی اوبونتو Ubuntu

تمرین با REST

بیایید تصور کنیم که در حال ساخت یک سایت مجموعه عکس هستیم. ما می‌خواهیم یک API برای پیگیری کاربران، مکان‌ها و عکس‌های آن مکان‌ها ایجاد کنیم. این سایت دارای index.html و style.css است. هر کاربر یک نام کاربری و یک رمز عبور دارد. هر عکس دارای یک مکان و یک مالک است (یعنی کاربری که عکس را گرفته است). هر مکان یک نام و آدرس خیابان دارد. آیا می توانید یک سیستم REST طراحی کنید که شامل موارد زیر باشد.

• ذخیره کاربران، عکس‌ها و مکان‌ها
• دسترسی به مکان ها و دسترسی به عکس های خاصی از یک مکان خاص

با نوشتن شروع کنید:

• چه نوع درخواست هایی می خواهیم داشته باشیم
• چه پاسخ هایی را سرور باید برگرداند
• نوع محتوای هر پاسخ چگونه باید باشد

مدل ها

{
  “user”: {
    "id": <Integer>,
    “username”: <String>,
    “password”:  <String>
  }
}
{
  “photo”: {
    "id": <Integer>,
    “venue_id”: <Integer>,
    “author_id”: <Integer>
  }
}
{
  “venue”: {
    "id": <Integer>,
    “name”: <String>,
    “address”: <String>
  }
}

درخواست ها و پاسخ ها

در این بخش، لیستی از درخواست‌هایی که برای مدیریت کاربران، مکان‌ها و عکس‌ها در API سایت مجموعه عکس استفاده می‌شود، ارائه شده است. این درخواست‌ها شامل GET, POST, PUT , DELETE هستند.

1. درخواست‌های GET

این درخواست‌ها برای دریافت داده‌ها از سرور استفاده می‌شوند.

دریافت صفحه اصلی GET /index.html Accept: text/html

پاسخ: 200 (OK) Content-Type: text/html

دریافت فایل استایل (CSS) GET /style.css Accept: text/css

پاسخ: 200 (OK) Content-Type: text/css

دریافت لیست مکان‌ها GET /venues Accept: application/json

پاسخ: 200 (OK) Content-Type: application/json

دریافت اطلاعات یک مکان خاص GET /venues/:id Accept: application/json

پاسخ:200 (OK) Content-Type: application/json

دریافت یک عکس خاص از یک مکان مشخصGET /venues/:id/photos/:id Accept: application/json

پاسخ:200 (OK) Content-Type: image/png

2. درخواست‌های POST

این درخواست‌ها برای ایجاد منابع جدید در سرور استفاده می‌شوند.

ایجاد کاربر جدیدPOST /users

پاسخ:201 (CREATED) Content-Type: application/json

ایجاد مکان جدیدPOST /venues

پاسخ:201 (CREATED) Content-Type: application/json

افزودن عکس جدید به یک مکان خاصPOST /venues/:id/photos

پاسخ:201 (CREATED) Content-Type: application/json

3. درخواست‌های PUT

این درخواست‌ها برای به‌روزرسانی اطلاعات یک منبع موجود استفاده می‌شوند.

به‌روزرسانی اطلاعات کاربرPUT /users/:id

پاسخ:200 (OK)

به‌روزرسانی اطلاعات یک مکانPUT /venues/:id

پاسخ:200 (OK)

به‌روزرسانی اطلاعات یک عکس خاصPUT /venues/:id/photos/:id

پاسخ:200 (OK)

4. درخواست‌های DELETE

این درخواست‌ها برای حذف یک منبع خاص از سرور استفاده می‌شوند.

حذف یک عکس خاص از یک مکان مشخصDELETE /venues/:id/photos/:id

پاسخ:204 (NO CONTENT)

حذف یک مکان خاصDELETE /venues/:id

پاسخ:204 (NO CONTENT)

سوالات متداول

در ادامه این مطلب برخی از سوالات متداولی که کاربران در رابطه با REST دارند، پاسخ داده شده است.

1. REST چیست؟

REST (Representational State Transfer) یک معماری برای طراحی سرویس‌های وب است که از متدهای HTTP برای ارتباط استفاده می‌کند.

2. REST API چیست؟

یک API که از اصول معماری REST پیروی می‌کند و بدون حالت (Stateless) است.

3. فرق بین REST و REST API چیست؟

REST یک سبک معماری است، اما REST API پیاده‌سازی این معماری در قالب یک رابط برنامه‌نویسی است.

4. چرا REST محبوب است؟

چون سادگی، کارایی، مقیاس‌پذیری و انعطاف‌پذیری دارد.

5. چه متدهایی در REST استفاده می‌شود؟

• GET: دریافت داده
• POST: ارسال داده جدید
• PUT: به‌روزرسانی داده
• DELETE : حذف داده

6. تفاوت REST و SOAP چیست؟

REST سبک و سریع است، ولی SOAP پیچیده و سنگین.

7. REST API چگونه داده را ارسال می‌کند؟

معمولاً با JSON یا XML.

8. Stateless در REST یعنی چه؟

یعنی هر درخواست مستقل است و سرور اطلاعات قبلی را ذخیره نمی‌کند.

9. آیا REST فقط برای وب است؟

نه، می‌تواند در اپلیکیشن‌های موبایل و حتی IoT هم استفاده شود.

10. REST محدودیت دارد؟

بله، مثلاً ارتباط دوطرفه بلادرنگ را پشتیبانی نمی‌کند

جمع بندی

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

اگر به دنبال یادگیری بیشتر درباره‌ی پیاده‌سازی REST API هستید، پیشنهاد می‌کنیم با تمرین و پیاده‌سازی پروژه‌های واقعی، مهارت خود را در این زمینه تقویت کنید.