نمای کلی REST. بخش 2: ارتباط بین مشتری و سرور

نمای کلی REST. بخش 1: REST چیست؟ در این بخش، ما عمیقاً به چگونگی ارتباط بین مشتری و سرور خواهیم پرداخت. در طول مسیر، اصطلاحات جدیدی را کشف کرده و آنها را توضیح خواهیم داد. برای اطمینان از واضح بودن همه چیز، ارتباط مشتری-سرور را با استفاده از یک برنامه RESTful به عنوان مثال تجزیه و تحلیل خواهیم کرد. فرض کنید ما در حال توسعه یک برنامه وب هستیم که اطلاعات مشتریان و سفارشات آنها را ذخیره می کند. به عبارت دیگر، سیستم ما قادر به انجام عملیات بر روی موجودیت های خاصی است: ایجاد، ویرایش و حذف آنها و نمایش اطلاعات مربوط به آنها. این نهادها خواهند بود:

• مشتریان (مشتریان)
• سفارشات (سفارشات مشتری)
• اقلام (محصولات)

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

درخواست ها

درخواست های مشتری تقریباً همیشه با استفاده از پروتکل HTTP انجام می شود. به طور کلی، درخواست های HTTP از چندین جزء تشکیل شده است:

• روش HTTP
• سرتیتر
• URI
• بدن درخواست

در زیر هر جزء را با جزئیات بیشتری در نظر خواهیم گرفت.

URI ها و منابع

داده هایی که مشتریان از طریق درخواست ها دریافت می کنند یا تغییر می دهند منابع نامیده می شود. ارتباط کلاینت و سرور تماماً در مورد دستکاری منابع است. در REST، منابع هر چیزی است که می توانید نامی برای آن بگذارید. به یک معنا، آنها مانند کلاس های جاوا هستند. در جاوا می توانیم برای هر چیزی کلاس ایجاد کنیم. بنابراین در REST، یک منبع می تواند هر چیزی باشد: یک کاربر، یک سند، یک گزارش، یک سفارش. این می تواند انتزاعی از یک موجودیت باشد یا چیزی خاص، به عنوان مثال، یک تصویر، ویدئو، انیمیشن یا فایل PDF. در مثال ما 3 منبع داریم:

• مشتریان (مشتریان)
• سفارشات (سفارشات مشتری)
• اقلام (محصولات)

مشتریان درخواست ها را به مکان های منبعی که به عنوان نقطه پایانی شناخته می شوند ارسال می کنند. به زبان ساده، نقطه پایانی مانند یک آدرس در شبکه است. با غواصی عمیق تر، می توانیم بگوییم که نقطه پایانی یک URI است ، یعنی دنباله ای از کاراکترها که یک منبع انتزاعی یا فیزیکی را مشخص می کند. شناسه منبع یکنواخت (URI) گاهی اوقات یک نقطه پایانی یا URI را مسیر می نامند که به معنای مسیر رسیدن به یک منبع است. برای اهداف این مقاله، ما از اصطلاح URI استفاده خواهیم کرد. هر منبع خاص باید یک URI منحصر به فرد داشته باشد. توسعه دهنده سرور مسئول اطمینان از این است که هر منبع همیشه URI خاص خود را دارد. در مثال ما، ما توسعه دهندگان هستیم، بنابراین به روشی که می دانیم این کار را انجام خواهیم داد. همانطور که معمولاً تخصیص شناسه های عددی به عنوان کلیدهای اصلی در یک پایگاه داده رابطه ای مرسوم است، هر منبع نیز شناسه مخصوص به خود را در REST دارد. شناسه منبع در REST اغلب با شناسه رکورد در پایگاه داده که اطلاعات مربوط به منبع را ذخیره می کند مطابقت دارد. REST URI ها معمولاً با شکل جمع اسمی شروع می شوند که برخی از منابع را توصیف می کند. مثلاً «مشتریان». به دنبال آن یک اسلش و سپس شناسه (ID) یک مشتری خاص وجود دارد. مثال ها:

• /customers - URI همه مشتریان موجود
• /customers/23 — URI یک مشتری خاص، یعنی مشتری با ID=23
• /customers/4 — URI یک مشتری خاص، یعنی مشتری با ID=4.

اما این همه ماجرا نیست. ما می توانیم URI را با افزودن سفارشات گسترش دهیم:

• /customers/4/orders — URI کلیه سفارشات انجام شده توسط مشتری شماره 4
• /customers/1/orders/12 — URI سفارش شماره 12 ساخته شده توسط مشتری شماره 1.

اگر گسترش را با افزودن محصولات بیشتر ادامه دهیم، دریافت می کنیم:

• /customers/1/orders/12/items — URI لیست تمامی محصولات به ترتیب شماره 12 ساخته شده توسط مشتری شماره 1.

همانطور که سطوح تودرتو را اضافه می کنیم، نکته مهم این است که URI ها را بصری کنیم.

روش HTTP

متد HTTP دنباله ای از هر کاراکتر است (به جز کاراکترهای کنترل و جداکننده ها) که عملیات اصلی در حال انجام بر روی منبع را نشان می دهد. چندین روش متداول HTTP وجود دارد. ما مواردی را که بیشتر در سرویس های RESTful استفاده می شوند فهرست می کنیم:

• GET - اطلاعاتی در مورد یک منبع خاص (از طریق شناسه آن) یا مجموعه ای از منابع دریافت کنید
• POST - یک منبع جدید ایجاد کنید
• PUT - تغییر یک منبع (از طریق شناسه آن)
• DELETE - حذف یک منبع (از طریق شناسه آن)

سرصفحه ها

درخواست ها و همچنین پاسخ ها حاوی هدرهای HTTP هستند. آنها اطلاعات اضافی در مورد درخواست (یا پاسخ) را منتقل می کنند. سرصفحه ها جفت های کلید-مقدار هستند. می‌توانید فهرست رایج‌ترین سرصفحه‌ها را در ویکی‌پدیا مشاهده کنید . در مورد REST، کلاینت‌ها اغلب یک هدر «پذیرش» در درخواست‌ها به سرور ارسال می‌کنند. این هدر برای اینکه به سرور بگوید مشتری در چه قالبی انتظار دریافت پاسخ را دارد نیاز است. فرمت های مختلف در لیستی از انواع MIME آورده شده است. MIME (افزونه های ایمیل چند منظوره اینترنتی) مشخصاتی برای رمزگذاری اطلاعات و قالب بندی پیام ها به منظور ارسال آنها از طریق اینترنت است. هر نوع MIME از دو قسمت تشکیل شده است که با یک اسلش از هم جدا شده اند - یک نوع و یک نوع فرعی. نمونه هایی از انواع MIME برای انواع مختلف فایل ها:

• متن - متن / ساده، متن / css، متن / html
• تصویر - تصویر/png، تصویر/jpeg، تصویر/گیف
• صوتی - صوتی / موج، صدا / MPEG
• ویدیو — ویدیو/mp4، ویدیو/ogg
• برنامه - application/json، application/pdf، application/xml، application/octet-stream

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

Accept:application/json

این هدر به سرور می گوید که مشتری انتظار دارد پاسخی با فرمت JSON دریافت کند.

درخواست بدن

این پیامی است که مشتری به سرور ارسال می کند. اینکه درخواست دارای بدنه است یا نه بستگی به نوع درخواست HTTP دارد. به عنوان مثال، درخواست‌های GET و DELETE معمولاً حاوی بدنه درخواستی نیستند. اما درخواست‌های PUT و POST می‌توانند - این فقط به هدف درخواست بستگی دارد. پس از همه، برای دریافت و/یا حذف داده ها با استفاده از یک شناسه (که در URL ارسال می شود)، نیازی به ارسال داده های اضافی به سرور ندارید. اما برای ایجاد یک منبع جدید (از طریق درخواست POST)، باید منبع را ارسال کنید. همین امر برای اصلاح یک منبع موجود نیز صادق است. در REST، بدنه درخواست اغلب در قالب XML یا JSON ارسال می شود. فرمت JSON رایج ترین است. فرض کنید می خواهیم برای ایجاد یک منبع جدید درخواستی را به سرور ارسال کنیم. اگر فراموش نکرده اید، نمونه اپلیکیشنی را در نظر گرفتیم که سفارشات مشتری را مدیریت می کند. فرض کنید می خواهیم مشتری جدیدی ایجاد کنیم. در مورد ما، ما اطلاعات مشتری زیر را ذخیره می کنیم: نام، ایمیل، شماره تلفن. سپس بدنه درخواست می تواند JSON زیر باشد:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

کنار هم قرار دادن درخواست ها

بنابراین، ما آنچه ممکن است در یک درخواست مشتری باشد را بررسی کرده ایم. اکنون چند نمونه از درخواست ها را همراه با توضیحات ارائه می کنیم

پاسخ

بیایید چند کلمه در مورد پاسخ سرور بگوییم. پاسخ معمولاً شامل بخش‌های زیر است:

• کد پاسخ
• سرصفحه ها
• بدن پاسخ

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

کدهای پاسخ HTTP

بیایید کدهای پاسخ HTTP را با جزئیات بیشتری در نظر بگیریم. کد وضعیت HTTP بخشی از اولین خط پاسخ سرور به درخواست‌هایی است که از طریق پروتکل HTTP انجام می‌شود. یک عدد صحیح متشکل از سه رقم اعشاری است. رقم اول کلاس کد وضعیت پاسخ را نشان می دهد. کد پاسخ معمولاً با یک عبارت توضیحی به زبان انگلیسی همراه می شود که با فاصله از هم جدا می شود. این عبارت دلیلی قابل خواندن برای انسان برای پاسخ است. مثال ها:

• 201 ایجاد شد
• 401 غیر مجاز
• 507 ذخیره سازی ناکافی

کد پاسخ نتیجه درخواست را به مشتری می گوید و به او اجازه می دهد تا اقدامات بعدی را انجام دهد. کدهای پاسخ به چند کلاس یا گروه تقسیم می شوند:

• 1XX - اطلاعاتی
• 2XX - این کدها نشان می دهد که درخواست مشتری با موفقیت دریافت و پردازش شده است
• 3XX - این کدها به مشتری اطلاع می‌دهند که برای تکمیل موفقیت‌آمیز عملیات، باید یک درخواست اضافی، معمولاً به یک URI دیگر، ارسال شود.
• 4XX - خطای مشتری. چنین کدهایی ممکن است ناشی از یک درخواست اشتباه باشد. مثال دیگر، کد معروف "404 Not Found" است که می تواند زمانی رخ دهد که مشتری یک منبع ناموجود را درخواست کند.
• 5XX - خطای سرور. اگر سرور مسئول شکست عملیات باشد، این کدها به کلاینت بازگردانده می شوند

نمای کلی REST. قسمت 3: ایجاد یک سرویس RESTful در Spring Boot