اپلیکیشنی که روی گوشی شماست، پایگاه دادهای در جیب ندارد. هر فهرستی که میبینید، هر تصویری که بار میشود و هر ثبتنامی که انجام میدهید، نتیجه گفتوگویی است میان اپ و سروری دور؛ گفتوگویی که با پیامهایی رد و بدل میشود. این پیامها به زبان مشترکی نیاز دارند و در وب، پرکاربردترین لهجه این زبان REST نام دارد.
REST یا انتقال وضعیت بازنمایی (Representational State Transfer) سبکی برای طراحی واسط برنامهنویسی (API) است؛ قراردادی درباره اینکه کدام طرف چه چیزی و چگونه بپرسد و طرف دیگر چه شکلی پاسخ دهد. وقتی میگوییم یک API استاندارد است، یعنی از این قرارداد بهدرستی پیروی میکند و هر توسعهدهندهای میتواند بدون حدسزدن، با آن کار کند.
در این مقاله با اصطلاحهای پایه REST آشنا میشویم: منبع (Resource)، روشهای HTTP، کدهای وضعیت و بیحافظه بودن (Stateless). سپس با پیگیری گفتوگوی یک سامانه رزرو با سرورش میبینیم این مفاهیم در عمل چگونه به هم میرسند و در نهایت، نشانههای یک API سالم را مرور میکنیم.
API بهعنوان قرارداد، نه جادو
واسط برنامهنویسی (Application Programming Interface) مجموعهای از نقاط اتصال است که یک سامانه در اختیار سامانههای دیگر میگذارد؛ مثل باجه بانک که مراجعهکننده از پشت آن درخواست میدهد و پاسخ میگیرد، بدون آنکه به اتاقهای داخلی راه پیدا کند. جزئیات داخلی از دید بیرون پنهان است؛ آنچه دیده میشود فقط قواعد درخواست و پاسخ است.
اهمیت استاندارد بودن در همین نقطه است: اگر هر باجه قواعد خودش را داشت، هر مراجعهای به یادگیری از صفر نیاز داشت. استاندارد بودن یعنی ساختار درخواستها و پاسخها قابل پیشبینی است؛ پس ساختن اپ جدید، اتصال پذیرنده جدید یا اشکالزدایی، سریعتر و کمخطا انجام میشود. برای همین است که هنگام انتخاب سرویس بیرونی، «API استاندارد داشتن» یک مزیت تبلیغاتی نیست، یک شرط همکاری است.
REST در یک نگاه: منبعها، افعال و بازنماییها
اصطلاح REST نخستینبار در پایاننامه دانشگاهی روی فیلدینگ، از طراحان اصلی وب، معرفی شد و ایده مرکزیاش ساده است: همهچیز را «منبع» ببین و به هر منبع یک نشانی ثابت بده. چیزی که سمت اپ جابهجا میشود هم خودِ منبع نیست، بلکه بازنمایی (Representation) آن است؛ مثلاً داده اتاق هتل در قالبی ساختاریافته و خوانا. همین سه عنصر — منبع، افعال استاندارد و بازنمایی — ستون فقرات هر API رستمانند (RESTful) را میسازد.
منبع (Resource): هرچیزی که اسم دارد
اتاق یک هتل، یک رزرو، فهرست مناسبتها و حتی پرونده یک پرداخت، همه منبعاند. در REST به هر منبع نشانیای میدهیم که با آن یکتا صدا زده شود؛ نشانی رزرو شماره ۱۲۰۴ چیزی شبیه reservations/1204 است. نکته مهم، قاعدهمند بودن است: منبعها اسم میگیرند، نه فعل؛ و نشانیهای شبیه به هم، ساختار شبیه به هم دارند. وقتی این یکنواختی رعایت شود، خواندن API ناشناخته هم مثل خواندن نقشهای با نشانههای آشنا میشود.
روشهای HTTP: افعالی با معنای توافقی
برای کار با منبعها، پروتکل HTTP چند فعل استاندارد در اختیار میگذارد که هر کدام معنای مشخصی دارند. زیبایی این افعال در آن است که همه سامانههای وب آنها را یکسان میفهمند؛ از مرورگر تا درگاه پرداخت. ستون «رفتار با تکرار» در جدول زیر را جدی بگیرید؛ در مقالههای بعدی این مجموعه خواهیم دید که همین ستون، سرنوشت تراکنشهای حساس را تعیین میکند.
| روش | معنای توافقی | رفتار با اجرای مجدد | نمونه در سامانه رزرو |
|---|---|---|---|
| GET | خواندن منبع بدون تغییر | بیخطر؛ اثر اضافه ندارد | دریافت فهرست اتاقهای خالی |
| POST | ساختن منبع یا اجرای فرآیند | معمولاً هر اجرا نتیجه تازه میسازد | ثبت یک رزرو جدید |
| PUT | جایگزینی کامل وضعیت منبع | تکرار به همان نتیجه میرسد | بهروزرسانی کامل اطلاعات مسافر |
| PATCH | تغییر بخشی از منبع | بسته به طراحی سرور | ویرایش تاریخ ورود یک رزرو |
| DELETE | حذف منبع مشخص | تکرار اثر تازهای ندارد | لغو رزرو با نشانی یکتا |
کدهای وضعیت: پاسخهایی که معنا حمل میکنند
پاسخ هر درخواست فقط داده نیست؛ یک کد وضعیت (Status Code) هم دارد که نتیجه را در یک نگاه اعلام میکند. خانواده ۲۰۰ یعنی موفقیت و ۲۰۱ مخصوص «ساخته شد» است؛ ۴۰۰ یعنی درخواست از سمت فرستنده نامعقول بود؛ ۴۰۱ و ۴۰۳ به ترتیب یعنی هویت نامعلوم است یا هویت روشن است اما اجازه نیست؛ ۴۰۴ یعنی منبع پیدا نشد و خانواده ۵۰۰ یعنی مقصر سمت سرور است. استفاده درست از این کدها باعث میشود اپ بهجای حدسزدن، تصمیم درست بگیرد: پیام خطا نشان دهد، دوباره تلاش کند یا کاربر را به صفحه ورود ببرد.
بیحافظه بودن (Stateless): هر درخواست، کامل و مستقل
در REST سرور از درخواستهای قبلی شما حافظهای نگه نمیدارد؛ هر درخواست باید همهچیز لازم را همراه داشته باشد، از مدرک هویت تا جزئیات کار. این قاعده که Stateless خوانده میشود، مثل کار با باجهای است که هر بار پرونده شما را از نو میخواهد. مزمن به نظر میرسد، اما مقیاسپذیری را ساده میکند: چون هیچ درخواستی به سرور خاصی گره نخورده، هر سروری میتواند هر درخواستی را پاسخ دهد.
قاعده طلایی REST: درخواست باید خودکفا باشد و پاسخ باید گویا؛ هیچکدام نباید به خاطرهای پنهان در سرور وابسته باشد.
نشانههای یک API استاندارد و سالم
- یکنواختی در نامگذاری منبعها و ساختار پاسخها؛ دادهها شبیه هماند، پس نشانیها و پیامهای خطا هم الگوی ثابت دارند.
- فرمت پاسخ شفاف (معمولاً JSON) و مستندسازی کامل؛ توسعهدهنده بیرونی بدون تماس تلفنی بتواند کارش را جلو ببرد.
- مدیریت خطای منظم: کد وضعیت درست همراه پیام گویا، بهجای پاسخهای مبهم و بیقاعده.
- احراز هویت و مجوز دسترسی روی همه مسیرها، نه فقط مسیرهایی که «مهم» به نظر میرسند.
- محدودیت نرخ (Rate Limiting) و نسخهبندی (Versioning) برای حفاظت از سرویس و تحول بدون شکستن همکاران قدیمی.
مثال کاربردی: گفتوگوی سامانه رزرو با سرور
فرض کنید سامانه رزرواسیون یک هتل را طراحی کردهاید و مسافری میخواهد اتاق رزرو کند. کل داستان، یک زنجیره ساده از درخواست و پاسخ است:
- اپ فهرست اتاقهای خالی را میخواهد: درخواستی از نوع GET برای منبع اتاقها با شرط تاریخ، همراه مدرک ورود کاربر. پاسخ با کد ۲۰۰ میآید و بدنه آن فهرست اتاقهاست.
- مسافر اتاق را انتخاب و تأیید میکند: اپ درخواست POST برای منبع رزروها میفرستد و جزئیات اتاق، تاریخ و مهمان را ضمیمه میکند. سرور رزرو را میسازد، با کد ۲۰۱ پاسخ میدهد و نشانی یکتای رزرو تازه را اعلام میکند.
- صفحه جزئیات رزرو باز میشود: یک GET ساده برای همان نشانی؛ باز هم کد ۲۰۰ و داده رزرو.
- مسافر نظرش عوض میشود: اپ DELETE برای همان نشانی میفرستد؛ سرور رزرو را لغو میکند و با کدی از خانواده موفقیت پاسخ میدهد.
دقت کنید که در هیچ مرحلهای «کارِ خاصی» از سرور خواسته نشد؛ همهچیز حول منبع رزرو و افعال استاندارد چرخید. همین الگو در فروشگاهها، بانکها و سرویسهای پیام تکرار میشود و همین قابلیت پیشبینی است که کار با APIهای مختلف را یادگرفتنی میکند.
مزایا، محدودیتها و خطاهای رایج
REST ساده، همهجا حاضر و همراه با ابزارهای فراوان است؛ مقیاسپذیری از جنس Stateless طبیعی است و پاسخهای GET قابلیت ذخیره موقت (Cache) دارند. اما این سبک برای هر سناریویی آرمانی نیست: وقتی داده لازم در چند منبع پراکنده است، اپ ناچار چند درخواست پشت هم میزند؛ یا وقتی از یک فهرست بزرگ فقط چند آیتم به کار میآید، داده اضافه رد و بدل میشود و هزینه ترافیک میپردازد.
خطاهای رایج طراحی هم معمولاً از جنس بیقاعدگی است: نشانیهایی که فعل دارند و با هم ناهماهنگاند، پاسخ موفق با کد خطا یا برعکس، و پنهانکردن وضعیت واقعی در متن آزاد بهجای کدهای استاندارد. این کژیها روز اول بیضرر به نظر میرسند، اما با بزرگشدن تیم و تعداد یکپارچهسازیها (Integration) به هزینهای دائمی تبدیل میشوند که هر تغییر جدید را کندتر میکند.
کاربرد عملی
اگر مدیر محصول هستید، این واژهها زبان جلسات فنی شماست؛ پرسش «این قابلیت با کدام منبع و کدام فعل انجام میشود؟» بسیاری از ابهامها را پیش از کدنویسی آشکار میکند. اگر توسعهدهنده هستید، فهرست نشانههای API سالم را معیار بازبینی طراحی قرار دهید. و اگر صاحب کسبوکار هستید، بدانید که هر اتصال به درگاه پرداخت، سامانه انبارداری یا سرویس پیام، سرانومی از جنس REST دارد؛ فهم این قرارداد به شما کمک میکند زمان و هزینه یکپارچهسازیها را واقعبینانه ببینید و در مذاکره با پذیرندهها پرسشهای دقیقتری بپرسید.
نکات کلیدی این مقاله
- REST سبکی برای طراحی API است که همهچیز را منبعی با نشانی یکتا میبیند و کار با منبع را به افعال استاندارد HTTP میسپارد.
- GET، POST، PUT، PATCH و DELETE هرکدام معنای توافقی روشنی دارند و استفاده درست از آنها پیشبینیپذیری میآورد.
- کدهای وضعیت زبان مشترک موفقیت و شکستاند؛ اپ با دیدن آنها تصمیم درست میگیرد.
- Stateless بودن یعنی هر درخواست خودکفاست و همین قاعده، توزیع بار بین سرورها را ساده میکند.
- استاندارد بودن، شرط همکاری میان تیمها و سامانههای مختلف است، نه یک جزئیات فنی اختیاری.
سوالات متداول
آیا REST و API یک چیزند؟
نه. API مفهوم کلی واسط برنامهنویسی است و REST فقط یکی از سبکهای طراحی آن. یک API میتواند رستمانند باشد یا از سبکهای دیگری پیروی کند؛ آنچه REST میآورد، قواعد منبعمحور و بیحافظه بودن است.
چرا سرور در REST حافظهای از کاربر نگه نمیدارد؟
چون حافظه سمت سرور یعنی وابستگی هر درخواست به سرور خاص. حذف این وابستگی اجازه میدهد بار بین سرورهای متعدد توزیع شود و اگر یکی از کارها متوقف شد، دیگری بدون آمادهسازی خاص جایگزینش شود.
بدون دانش برنامهنویسی، فهم REST به چه کار میآید؟
اگر با تیم فنی کار میکنید، این واژهها زبان جلساتاند. فهم مفهوم منبع، فعل و کد وضعیت کمک میکند نیازمندیها را دقیقتر بگویید، برآورد اتصالهای بیرونی را واقعبینانه ببینید و در انتخاب سرویسها پرسشهای بهتری بپرسید.
