REST architectureمفاهیم

REST چیست؟

REST مخفف Representational State Transfer و یک Architectural Style برای طراحی Web API است. در REST، هر چیزی که سیستم روی آن عملیات انجام می‌دهد به‌عنوان یک Resource دیده می‌شود و از طریق URI در دسترس قرار می‌گیرد.
Client با استفاده از HTTP Method‌ها روی این Resourceها عملیات انجام می‌دهد و Server نتیجه را در قالب Response برمی‌گرداند.

REST architecture یعنی چه؟

منظور از REST architecture مجموعه‌ای از اصول طراحی API است که باعث می‌شود سرویس:

• ساده‌تر فهمیده شود

• Scalable باشد

• بین Client و Server Decoupling ایجاد شود

• تست، توسعه و نگهداری آن راحت‌تر شود

در معماری REST، تمرکز روی Resource-based design است؛ نه روی Action-based design.

Resource در REST چیست؟

در REST، موجودیت‌های بیزینسی سیستم مثل Customer، Account، Order، CreditType و ... به‌عنوان Resource شناخته می‌شوند.
هر Resource باید یک آدرس مشخص یا URI داشته باشد.

مثال:

• /customers

• /customers/123

• /accounts/456

• /credit-types

REST روی چه چیزی بنا شده است؟

REST معمولاً روی HTTP پیاده‌سازی می‌شود و از قابلیت‌های خود HTTP استفاده می‌کند:

• Method

• URI

• Status Code

• Headers

• Content Type

• Caching

یعنی REST چیز جدا از HTTP نیست؛ بلکه از HTTP به‌صورت استاندارد و معنادار استفاده می‌کند.

اصول مهم REST architecture

1) Client-Server

در REST، Client و Server از هم جدا هستند.
Client فقط درخواست می‌فرستد و UI یا مصرف سرویس را مدیریت می‌کند؛ Server مسئول Business Logic، Validation، Data Access و تولید Response است.
این جداسازی باعث می‌شود Frontend و Backend مستقل‌تر توسعه پیدا کنند.

2) Stateless

هر Request باید به‌صورت مستقل قابل پردازش باشد و Server نباید برای فهم Request جدید به وضعیت قبلی Client وابسته باشد.
یعنی هر اطلاعات لازم برای پردازش باید داخل همان Request وجود داشته باشد؛ مثل:

• Authentication Token

• Path Parameter

• Query Parameter

• Request Body

نکته :
در REST، Session State نباید روی Server نگه‌داری شود به شکلی که Request بعدی به آن وابسته باشد. اگر درخواست دوم فقط با دانستن وضعیت درخواست اول قابل پردازش باشد، رفتار کاملاً RESTful نیست.

3) Resource-Oriented

در REST باید API را بر اساس Resource طراحی کرد، نه بر اساس اسم عملیات.
یعنی به‌جای اینکه Endpointها شبیه فعل باشند، بهتر است بر اساس اسم موجودیت طراحی شوند.

بهتر:

• GET /customers/123

• POST /customers

• PUT /customers/123

ضعیف‌تر:

• /getCustomer

• /createCustomer

• /deleteCustomer

4) Uniform Interface

REST باید یک رابط یکنواخت و قابل پیش‌بینی داشته باشد.
یعنی Client از روی HTTP Method، URI، Status Code و ساختار Response بتواند رفتار API را بفهمد.
برای مثال:

• GET برای دریافت

• POST برای ایجاد

• PUT/PATCH برای ویرایش

• DELETE برای حذف

5) Representation of Resource

Client معمولاً خود Resource را مستقیم نمی‌گیرد، بلکه Representation آن را دریافت می‌کند؛ مثلاً به‌صورت JSON یا XML.
مثلاً Resource ممکن است «مشتری با شناسه 123» باشد، اما چیزی که Client می‌بیند نمایش JSON آن مشتری است.

مثال:

{
  "id": 123,
  "name": "Ali",
  "status": "ACTIVE"
}

6) Cacheable

Response در REST می‌تواند Cacheable باشد.
یعنی Server می‌تواند با استفاده از Headerهایی مثل Cache-Control یا ETag مشخص کند که آیا پاسخ قابل Cache شدن هست یا نه.
این ویژگی برای بهبود Performance و کاهش بار Server مهم است.

7) Layered System

در معماری REST، Client لازم نیست بداند دقیقاً با خود سرویس اصلی صحبت می‌کند یا با یک Gateway، Load Balancer، Proxy یا Cache Layer.
یعنی بین Client و Server می‌توان چند لایه قرار داد بدون اینکه قرارداد API برای Client تغییر کند.

تفاوت نگاه RESTful با API معمولی

هر API لزوماً RESTful نیست.
API زمانی به REST نزدیک‌تر است که:

• Resource-based طراحی شده باشد

• از HTTP Method درست استفاده کند

• Stateless باشد

• Status Codeهای درست برگرداند

• ساختار Endpointها معنادار و یکنواخت باشد

نمونه طراحی RESTful

برای Customer:

• GET /customers → دریافت لیست مشتریان

• GET /customers/123 → دریافت جزئیات مشتری

• POST /customers → ایجاد مشتری جدید

• PUT /customers/123 → ویرایش کامل مشتری

• PATCH /customers/123 → ویرایش بخشی از اطلاعات مشتری

• DELETE /customers/123 → حذف مشتری

در این مدل، Resource = customer است و Method نوع عملیات را مشخص می‌کند.

نکات مهم REST architecture

• REST یک Protocol نیست؛ یک Architectural Style است.

• در REST، تمرکز روی Resource است نه اسم عملیات.

• URI باید معرف Resource باشد، نه Action.

• HTTP Method باید معنی‌دار انتخاب شود.

• GET نباید داده را تغییر دهد.

• DELETE برای حذف است، نه GET یا POST.

• Stateless بودن یعنی هر Request مستقل باشد و اطلاعات لازم را همراه خود داشته باشد.

• Status Code باید با نتیجه واقعی عملیات هماهنگ باشد.

• REST خوب یعنی Predictable API Design، نه صرفاً داشتن URL و JSON.

نمونه پاسخ کوتاه

REST architecture یک Architectural Style برای طراحی Web API است که در آن سیستم بر پایه Resourceها طراحی می‌شود. هر Resource با یک URI مشخص می‌شود و Client با استفاده از HTTP Methodهایی مثل GET، POST، PUT و DELETE روی آن عملیات انجام می‌دهد. از مهم‌ترین ویژگی‌های REST می‌توان به Client-Server، Stateless، Uniform Interface، Cacheable و Layered System اشاره کرد. هدف REST طراحی APIهای ساده، قابل‌فهم، مقیاس‌پذیر و استاندارد است.

کلیدواژه‌ها

REST | RESTful API | Architectural Style | Resource | URI | Endpoint | Representation | HTTP Method | GET | POST | PUT | PATCH | DELETE | Client-Server | Stateless | Uniform Interface | Cacheable | Layered System | Resource-based design | Action-based design | JSON | Status Code | Cache-Control | ETag | Scalability | Decoupling

توضیح و کاربرد کلیدواژه‌ها

REST (سبک معماری برای طراحی API بر پایه Resource و HTTP): برای طراحی Web API‌های استاندارد، قابل‌فهم و مقیاس‌پذیر استفاده می‌شود.

RESTful API (APIای که اصول REST را رعایت می‌کند): برای توصیف APIهایی به کار می‌رود که Resource-based، Stateless و مبتنی بر HTTP semantics هستند.

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

Resource (موجودیت بیزینسی که API روی آن عملیات انجام می‌دهد): در طراحی Endpointهایی مثل /customers، /accounts و /orders کاربرد دارد.

URI (شناسه آدرس‌دهی Resource): برای شناسایی و دسترسی به Resource در API استفاده می‌شود.

Endpoint (آدرس قابل فراخوانی یک API یا Resource): در Swagger، Postman و طراحی تست API کاربرد دارد.

Representation (نمایش یک Resource در قالبی مثل JSON یا XML): برای توضیح این نکته استفاده می‌شود که Client معمولاً خود Resource را مستقیم نمی‌گیرد، بلکه نمایش آن را دریافت می‌کند.

HTTP Method (نوع عملیات روی Resource): برای مشخص کردن عملیات Read / Create / Update / Delete در API استفاده می‌شود.

GET (دریافت اطلاعات بدون تغییر دادن داده): برای استعلام، جستجو و دریافت جزئیات کاربرد دارد.

POST (ایجاد Resource جدید یا انجام عملیات غیر idempotent): برای ثبت اطلاعات جدید استفاده می‌شود.

PUT (جایگزینی کامل Resource موجود): برای Update کامل کاربرد دارد.

PATCH (ویرایش بخشی از Resource): برای Update جزئی استفاده می‌شود.

DELETE (حذف Resource): برای عملیات حذف اطلاعات کاربرد دارد.

Client-Server (جداسازی نقش Client و Server در معماری): برای استقلال Frontend و Backend، ساده‌تر شدن توسعه و کاهش Coupling استفاده می‌شود.

Stateless (مستقل بودن هر Request و عدم وابستگی به وضعیت قبلی روی Server): برای طراحی APIهای مقیاس‌پذیرتر، ساده‌تر و قابل‌تست‌تر استفاده می‌شود.

Uniform Interface (رابط یکنواخت و قابل پیش‌بینی بین Client و Server): برای این استفاده می‌شود که Client با دیدن Method، URI و Status Code بتواند رفتار API را بفهمد.

Cacheable (قابلیت Cache شدن Responseها): برای بهبود Performance و کاهش بار روی Server کاربرد دارد.

Layered System (چندلایه بودن معماری بدون آشکار شدن جزئیات برای Client): در معماری‌هایی که Gateway، Proxy، Load Balancer یا Cache Layer دارند کاربرد دارد.

Resource-based design (طراحی API بر پایه اسم موجودیت‌ها نه اسم عملیات): برای طراحی RESTful API استاندارد استفاده می‌شود.

Action-based design (طراحی API بر پایه نام عملیات مثل getCustomer یا createUser): معمولاً در طراحی RESTful ضعیف‌تر است و در آزمون ممکن است به‌عنوان طراحی غیراستاندارد مطرح شود.

JSON (فرمت رایج نمایش داده در API): برای Request Body و Response Body در اکثر APIهای REST استفاده می‌شود.

Status Code (نتیجه پردازش Request در سطح HTTP): برای تشخیص Success، Client Error و Server Error در تست API استفاده می‌شود.

Cache-Control (Header کنترلی برای سیاست Cache): برای مشخص کردن مدت و نحوه Cache شدن Response استفاده می‌شود.

ETag (شناسه نسخه یا وضعیت Resource برای Cache Validation): برای Caching، Conditional Request و بهینه‌سازی مصرف شبکه کاربرد دارد.

Scalability (توانایی سیستم برای پاسخ‌گویی به بار بیشتر بدون افت شدید کیفیت): یکی از مزیت‌های معماری REST و طراحی Stateless است.

Decoupling (کاهش وابستگی مستقیم بین اجزای سیستم): در توضیح مزیت Client-Server separation و معماری تمیز API استفاده می‌شود.