REST چیست؟ و چه کاربردی دارد

REST یا REpresentational State Transfer، یک سبک معماری برای ارائه استانداردهایی بین سیستم‌های کامپیوتری در اینترنت است که ارتباط سیستم‌ها با یکدیگر را آسان‌تر می‌کند. سیستم‌های سازگار با REST، که اغلب سیستم‌های RESTful نامیده می‌شوند، با نحوه بدون وضعیت بودنشان مشخص می‌شوند و دغدغه ‌های کلاینت و سرور را از هم جدا می‌کنند. ما در ادامه به این مسائل خواهیم پرداخت که این عبارات به چه معنا هستند و چرا آنها ویژگی های مفیدی برای خدمات در اینترنت هستند.

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

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

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

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

بدون حالت

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

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

این شرایط بدون حالت، به برنامه‌های RESTful کمک می‌کنند تا به عملکرد سریع، اطمینان و مقیاس‌پذیری بالایی دست یابند. چنین قابلیت هایی در یک برنامه می‌تواند سبب شود برنامه های REST بتوانند بدون تأثیر بر کل سیستم، حتی در حین کارکرد سیستم، مدیریت، به‌ روز رسانی و استفاده مجدد شوند.

اکنون، نحوه برقراری ارتباط بین کلاینت و سرور را در هنگام پیاده سازی یک رابط RESTful بررسی خواهیم کرد.

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

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

دریافت درخواست

REST مستلزم آن است که یک کلاینت به منظور بازیابی یا تغییر داده های روی سرور، درخواستی به سرور ارائه کند. یک درخواست به طور کلی شامل موارد زیر است:

یک فعل HTTP که مشخص می کند چه نوع عملیاتی باید انجام شود
یک هدر، که به کلاینت اجازه می دهد اطلاعات مربوط به درخواست خود را ارسال کند
یک مسیر به یک منبع
یک متن اختیاری پیام حاوی داده های تکمیلی

افعال HTTP

4 فعل اصلی HTTP وجود دارد که ما در درخواست ها برای تعامل با منابع در یک سیستم REST استفاده می کنیم:

GET - یک منبع خاص (یا شناسه id) یا مجموعه ای از منابع را دریافت می کند
POST — یک منبع جدید ایجاد کنید
PUT — به روز رسانی یک منبع خاص (بر اساس شناسه)
DELETE - حذف یک منبع خاص با شناسه

هدرها و پارامترهای پذیرش

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

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

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

انواع دیگر و زیرگروه های رایج:

image — image/png, image/jpeg, image/gif
audio — audio/wav, audio/mpeg
video — video/mp4, video/ogg
application — application/json, application/pdf, application/xml, application/octet-stream

به عنوان مثال، یک کلاینت که به منبعی با شناسه 23 در یک منبع مقالات روی سرور دسترسی پیدا می کند، ممکن است درخواست GET را مانند این ارسال کند:

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، که شی را از منبع مشتریان با شناسه مشخص شده بازیابی می کند. DELETE fashionboutique.com/customers/:id - شی را از منبع مشتریان با شناسه مشخص شده حذف می کند.

ارسال پاسخ ها

انواع محتوا

در مواردی که سرور در حال ارسال داده به کلاینت است، سرور باید content-type (نوع محتوا) را در هدر پاسخ خود قرار دهد. فیلد هدر content-type به کلاینت هشدار می دهد که چه نوع داده ای در بدنه پاسخ، ارسال می شود. content-type همانطور که در فیلد accept هدر درخواست توضیح داده شد، از نوع MIME ها هستند. نوع محتوایی که سرور در پاسخ خود ارسال می کند باید یکی از گزینه هایی باشد که کلاینت در قسمت accept درخواست خود مشخص کرده است.

به عنوان مثال، هنگامی که کلاینت می خواهد به مقاله ای با شناسه 23 دسترسی پیدا کند و درخواستی با GET به صورت زیر ارسال می کند:

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

سرور ممکن است محتوا را با هدری به صورت زیر پاسخ دهد:

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

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

کدهای پاسخ

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

نیاز به کمک یا مشاوره دارید؟ با شماره 77637159-021 تماس بگیرید. ما آماده پاسخگویی هستیم!

کد وضعیت	معنی
200 (OK)	این پاسخ استاندارد برای درخواست های موفق HTTP است.
201 (CREATED)	این پاسخ استاندارد برای درخواست HTTP است که منجر به ایجاد موفقیت آمیز یک مورد یا شی می شود.
204 (NO CONTENT)	این پاسخ استاندارد برای درخواست های موفق HTTP است، که در آن هیچ چیزی در بدنه پاسخ بازگردانده نمی شود.
400 (BAD REQUEST)	فرمت درخواست کلاینت ناخوانا بود، درخواست قابل پردازش نیست. این خطا می تواند به دلیل عدم رعایت دستورات نحوی در درخواست، اندازه بیش از حد، یا خطای های دیگر در درخواست کلاینت باشد.
403 (FORBIDDEN)	مشتری اجازه دسترسی به این منبع را ندارد.
404 (NOT FOUND)	منبع در حال حاضر یافت نشد. ممکن است حذف شده باشد یا هنوز وجود نداشته باشد.
500 (INTERNAL SERVER ERROR)	پاسخ عمومی برای یک ایراد غیرمنتظره در سمت سرور..

برای هر فعل HTTP، کدهای وضعیت مورد انتظاری وجود دارد که سرور باید پس از موفقیت آن را بازگرداند:

GET — بازگشت 200 (OK)
POST — بازگشت 201 (CREATED)
PUT — برگرداندن 200 (OK)
DELETE — برگرداندن 204 (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@noyasystem.com”
}
}

سپس سرور یک شناسه برای آن شی تولید می کند و هدی به صورت زیر ارسال می کند:

201 (CREATED)
Content-type: application/json

برای مشاهده یک مشتری، با تعیین شناسه آن مشتری، آن را دریافت می کنیم:

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

پاسخ سرور، هدری به این صورت است:

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

و به دنبال آن داده های منبع مشتری با شناسه 23 در قالب application/json قرار می گیرند.

می‌توانیم آن مشتری را با قرار دادن داده‌های جدید به ‌روز رسانی کنیم:

PUT http://fashionboutique.com/customers/123
Body:
{
“customer”: {
“name” = “Scylla Buss”,
“email” = “scyllabuss1@noyasystem.com”
}
}

پاسخ سرور، هدری با کد وضعیت: 200 (OK) خواهد بود تا به کلاینت اطلاع دهد که مورد مد نظر با شناسه 123 تغییر یافته است.

همچنین می توانیم آن مشتری را با مشخص کردن شناسه آن حذف کنیم:

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

پاسخ سرور، دارای هدری حاوی کد وضعیت: 204 (NO CONTENT) است که به کلاینت اطلاع می دهد که مورد مد نظر با شناسه 123 حذف شده است و هیچ چیز در بدنه پاسخ وجود ندارد.

با REST تمرین کنید

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

آیا می توانید یک سیستم REST طراحی کنید که شامل موارد زیر باشد؟

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

ابتدا با خلاصه نویسی شروع می کنیم:

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

راه حل ممکن برای Model ها

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

راه حل ممکن برای Request ها و Response ها

GET Requests

Request- GET /index.html Accept: text/html Response- 200 (OK) Content-type: text/html

Request- GET /style.css Accept: text/css Response- 200 (OK) Content-type: text/css

Request- GET /venues Accept:application/json Response- 200 (OK) Content-type: application/json

Request- GET /venues/:id Accept: application/json Response- 200 (OK) Content-type: application/json

Request- GET /venues/:id/photos/:id Accept: application/json Response- 200 (OK) Content-type: image/png

POST Requests

Request- POST /users Response- 201 (CREATED) Content-type: application/json

Request- POST /venues Response- 201 (CREATED) Content-type: application/json

Request- POST /venues/:id/photos Response- 201 (CREATED) Content-type: application/json

PUT Requests

Request- PUT /users/:id Response- 200 (OK)

Request- PUT /venues/:id Response- 200 (OK)

Request- PUT /venues/:id/photos/:id Response- 200 (OK)

DELETE Requests

Request- DELETE /venues/:id Response- 204 (NO CONTENT)

Request- DELETE /venues/:id/photos/:id Response- 204 (NO CONTENT)

CRUD چیست؟

ایجاد، خواندن، به ‌روز رسانی و حذف (CRUD) چهار عملکرد اساسی هستند که مدل‌ها حداکثر باید بتوانند انجام دهند.

CREATE، READ، UPDATE، DELETE

هنگامی که در حال ساخت API هستیم، می خواهیم مدل های ما چهار نوع عملکرد اساسی را ارائه دهند. مدل باید قادر به ایجاد، خواندن، به روز رسانی و حذف منابع باشد. برنامه نویسان اغلب به این توابع با مخفف آنها یعنی CRUD اشاره می کنند. یک مدل باید حداکثر توانایی انجام این چهار عملکرد اصلی را داشته باشد تا کامل شود. اگر عملی را نتوان با یکی از این چهار عملیات توصیف کرد، در این صورت، خودش باید به طور بالقوه مدلی برای خود باشد.

الگوی CRUD در ساخت برنامه های کاربردی تحت وب رایج است، زیرا چارچوبی به یاد ماندنی و تکرارپذیر برای یادآوری به توسعه دهندگان از نحوه ساخت مدل های کامل و قابل استفاده فراهم می کند. برای مثال، بیایید سیستمی را برای پیگیری کتاب های یک کتابخانه تصور کنیم. در این پایگاه داده کتابخانه فرضی، می توانیم تصور کنیم که یک منبع کتاب وجود دارد که اشیاء کتاب را ذخیره می کند. بیایید بگوییم که شی کتاب به شکل زیر است:

“book”: {
"id": ,
“title”: ,
“author”: ,
“isbn”:
}

برای قابل استفاده کردن این سیستم کتابخانه، می‌خواهیم مطمئن شویم که مکانیسم‌های واضحی برای تکمیل عملیات CRUD وجود دارد:

Create - این تابعی است که وقتی می خواهیم یک کتاب جدید به فهرست کتابخانه خود اضافه کنیم، آن را فراخوانی می کنیم. برنامه ای که تابع را فراخوانی می کند مقادیر "title"، "author" و "isbn" را ارائه می دهد. پس از فراخوانی این تابع، باید یک رکورد جدید در منابع کتاب مربوط به این کتاب جدید به وجود آید. علاوه بر این، به رکورد جدید یک شناسه منحصر به فرد اختصاص داده می شود که می توان از آن برای دسترسی به آن منبع بعدا استفاده کرد.

Read - این شامل تابعی است که برای دیدن کتاب‌های موجود در فهرست فراخوانی می‌شود. این فراخوانی تابع، کتاب‌های موجود در فهرست را تغییر نمی‌دهد - به سادگی منبع را بازیابی می‌کند و نتایج را نمایش می‌دهد. ما همچنین عملکردی برای بازیابی یک کتاب داریم که می‌توانیم عنوان، نویسنده یا ISBN را برای آن ارائه کنیم. باز هم تکرار می کنیم که کتاب فراخوانی شده، اصلاح نمی شود، فقط بازیابی می شود.

Update - عملکردی باید وجود داشته باشد که در زمانی که می خواهیم اطلاعات مربوط به یک کتاب را تغییر دهیم، آن را فراخوانی کنیم. برنامه ای که این تابع را فراخوانی می کند باید مقادیر جدید "title"، "author" و "isbn" را فراهم می دهد. پس از فراخوانی این تابع، رکورد مربوطه در منبع کتاب حاوی فیلدهای جدید خواهد شد.

Delete -باید تابعی برای حذف یک کتاب کتابخانه از فهرست نیز وجود داشته باشد. برنامه ای که این تابع را فراخوانی می کند یک یا چند مقدار ("عنوان"، "نویسنده" و یا "isbn") را برای شناسایی کتاب ارائه می دهد و سپس این کتاب از منبع کتاب حذف می شود. پس از فراخوانی این تابع، منبع کتاب باید شامل همه کتاب‌هایی باشد که قبلا وجود داشته بودند به جز کتابی که به تازگی حذف شده است.

CRUD و REST

در یک محیط REST، CRUD به ترتیب معادل با متدهای POST، GET، PUT و DELETE است. اینها عناصر اساسی یک سیستم ذخیره سازی پایدار هستند.

در طول این مقاله، ما از استانداردها و کدهای که معمولا توسط توسعه دهندگان هنگام ایجاد برنامه های RESTful رعایت می شوند، استفاده خواهیم کرد. استانداردها ممکن است قدری متفاوت باشند، بنابراین با مقادیر و کدهای بازگشتی مختلف تمرین کنید تا با الگوی CRUD بیشتر آشنا شوید.

تصور کنید ما با سیستمی کار می کنیم که غذاها و قیمت های مربوط به آنها را برای یک رستوران پیگیری می کند. بیایید ببینیم که چگونه عملیات CRUD را اجرا می کنیم.

Create

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

به عنوان مثال، بیایید تصور کنیم که می خواهیم یک ماده غذایی جدید را به لیست ذخیره شده غذاهای این رستوران اضافه می کنیم، و غذاها در یک منبع غذاها ذخیره می شوند. اگر بخواهیم مورد جدیدی را ایجاد کنیم، از یک درخواست POST استفاده می کنیم:

Request:

POST http://www.myrestaurant.com/dishes/
Body -

{
"dish": {
"name": “Avocado Toast”,
"price": 8
}
}

این کد، یک آیتم جدید با مقدار نام «Avocado Toast» و قیمت 8 هزار تومان ایجاد می‌کند. پس از ایجاد موفقیت‌آمیز، سرور باید یک هدر با پیوندی به منبع تازه ایجاد شده، همراه با کد پاسخ HTTP 201 ( CREATED) به کلاینت ارسال کند.

Response:

Status Code - 201 (CREATED)

Body -

{
"dish": {
"id": 1223,
"name": “Avocado Toast”,
"price": 8
}
}

از این پاسخ می بینیم که ظرف با نام Avocado Toast و قیمت 8 هزار تومان، با موفقیت ساخته شده و به منبع غذاها اضافه شده است.

Read

برای خواندن منابع در محیط REST از روش GET استفاده می کنیم. خواندن یک منبع هرگز نباید هیچ اطلاعاتی را تغییر دهد و فقط باید آن را بازیابی کند. اگر 10 بار متوالی با همان اطلاعات با GET ارتباط برقرار کنید، باید همان پاسخی را که در اولین درخواست، دریافت کرده بودید را در آخرین درخواست خود دریافت کنید.

از GET می توان برای خواندن کل لیست موارد استفاده نیز کرد:

Request:

GET http://www.myrestaurant.com/dishes/
Response: Status Code - 200 (OK)

Body -

{
"dishes": [
{
"id": 1,
"name": “Spring Rolls”,
"price": 6
},
{
"id": 2,
"name": “Mozzarella Sticks”,
"price": 7
},
...
{
"id": 1223,
"name": “Avocado Toast”,
"price": 8
},
{
"id": 1224,
"name": “Muesli and Yogurt”,
"price": 5
}
]
}

درخواست های GET همچنین می توانند برای خواندن یک مورد خاص نیز استفاده شوند، زمانی که شناسه آن در درخواست مشخص شده باشد:

Request:

GET http://www.myrestaurant.com/dishes/1223
Response: Status Code - 200 (OK)

Body -

{
"id": 1223,
"name": “Avocado Toast”,
"price": 8
}

پس از این درخواست، هیچ اطلاعاتی در پایگاه داده تغییر نمی کند. مورد با شناسه 1223 از منبع غذاها بازیابی می شود، و تغییری روی آن صورت نخواهد گرفت. وقتی هیچ خطایی وجود نداشته باشد، GET HTML یا JSON منبع مورد نظر را به همراه یک کد پاسخ 200 (OK) برمی گرداند. اگر خطایی وجود داشته باشد، اغلب کد پاسخ 404 (یافت نشد) را برمی گرداند.

Update

PUT یک روش HTTP است و برای عملیات CRUD، از Update استفاده می شود.

مثلا اگر قیمت نان تست آووکادو بالا رفته است، باید وارد دیتابیس شویم و آن اطلاعات را به روز کنیم. ما می توانیم این کار را با یک درخواست PUT نیز انجام دهیم.

Request:

PUT http://www.myrestaurant.com/dishes/1223
Body -

{
"dish": {
"name": “Avocado Toast”,
"price": 10
}
}

این درخواست باید مورد با شناسه 1223 را تغییر دهد به طوری که ویژگی‌های آن، به ویژگی هایی که در بدنه درخواست ارائه شده است، به روز رسانی شود. این غذا با شناسه 1223 هنوز باید نام "Avocado Toast" را داشته باشد، اما ارزش قیمت آن اکنون باید 10 هزار تومان باشد، در حالی که قبلا 8 هزار تومان بود.

Response: Status Code - 200 (OK)

Body -

{
"dish": {
"name": “Avocado Toast”,
"price": 10
}
}

پاسخ شامل کد وضعیت 200 (OK) است که نشان می دهد عملیات موفقیت آمیز بوده است. به صورت اختیاری، پاسخ می تواند از کد وضعیت 204 (NO CONTENT) استفاده کند و شامل بدنه پاسخ نباشد. این تصمیم بستگی به سرور و توع درخواست کلاینت دارد.

Delete

عملیات CRUD Delete با روش HTTP DELETE یکسان است و هر دو برای حذف یک منبع از سیستم استفاده می شوند.

فرض کنید که کمبود آووکادو در جهان به نقطه بحرانی خود رسیده است و ما دیگر نمی توانیم این غذای لذیذ مدرن را به هیچ وجه سرو کنیم. ما باید به پایگاه داده خود برویم و موردی را که با "Avocado Toast" مطابقت دارد، حذف کنیم، که می دانیم شناسه آن 1223 است.

Request:

DELETE http://www.myrestaurant.com/dishes/1223

چنین درخواستی، در صورت موفقیت آمیز بودن، کد پاسخ 204 (NO CONTENT)، بدون بدنه پاسخ را برمی گرداند. منبع غذاها دیگر نباید حاوی شی غذایی با شناسه 1223 باشد.

Response: Status Code - 204 (NO CONTENT)

Body - None

با ارسال درخواست GET در منبع غذاها، و پس از DELETE شدن شناسه 1223، فهرست اصلی تمام غذاها برگردانده خواهد شد اما رکورد {"id": 1223، "name": "Avocado Toast"، "price": 10} دیگر وجود ندارد. اگر بخواهیم روی موردی با شناسه 1223 که به تازگی آن را حذف کرده ایم، یک GET فراخوانی کنیم، یک کد پاسخ 404 (یافت نشد) دریافت می کنیم و وضعیت سیستم باید بدون تغییر باقی بماند.