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

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

• مشتریان - مشتریان؛
• سفارشات - سفارشات مشتری؛
• اقلام - کالا.

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

درخواست ها

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

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

در زیر به هر یک از اجزای سازنده با جزئیات بیشتری نگاه خواهیم کرد.

URI و منابع

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

• مشتریان - مشتریان؛
• سفارشات - سفارشات مشتری؛
• اقلام - کالا.

مشتریان درخواست ها را به اصطلاح به نقاط پایانی یا نقاط پایانی ارسال می کنند. به بیان خیلی ساده، نقطه پایانی چیزی شبیه یک آدرس در شبکه است. برای عمیق تر، نقطه پایانی یک URI است : دنباله ای از کاراکترها که یک منبع انتزاعی یا فیزیکی را مشخص می کند. Uniform Resource Identifier - یک شناسه منبع یکپارچه. گاهی اوقات نقطه پایانی، یا URI، یک مسیر نامیده می شود - مسیر به یک منبع. برای اهداف این مقاله، ما از اصطلاح URI استفاده خواهیم کرد. هر منبع خاص باید یک URI منحصر به فرد داشته باشد. مسئولیت اطمینان از اینکه هر منبع همیشه URI خاص خود را دارد بر دوش توسعه دهنده سرور است. در مثال ما، ما توسعه دهندگان هستیم، بنابراین به روشی که می دانیم این کار را انجام خواهیم داد. همانطور که در یک پایگاه داده رابطه ای معمولاً مرسوم است که کلید اصلی را روی یک شناسه عددی خاص تنظیم کنیم، در REST نیز هر منبع دارای شناسه خاص خود است. اغلب اتفاق می افتد که شناسه یک منبع در REST با شناسه رکورد در پایگاه داده ای که اطلاعات مربوط به این منبع در آن ذخیره می شود مطابقت دارد. REST URI ها معمولاً با شکل جمع اسمی شروع می شوند که برخی از منابع را توصیف می کند. مثلا از کلمه مشتریان. در مرحله بعد، یک شناسه از طریق یک اسلش نشان داده می شود - شناسه یک مشتری خاص. مثال ها:

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

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

• /clients/4/orders — URI کلیه سفارشات مشتری شماره 4.
• /clients/1/orders/12 - URI سفارش شماره 12 مشتری شماره 1.

اگر این زنجیره را ادامه دهیم و کالاها را اضافه کنیم، دریافت می کنیم:

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

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

روش HTTP

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

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

سرفصل ها

درخواست ها و همچنین پاسخ ها حاوی هدرهای HTTP هستند. آنها اطلاعات اضافی در مورد درخواست (یا پاسخ) ارسال می کنند. سرصفحه ها جفت های کلید-مقدار هستند. می‌توانید فهرست رایج‌ترین عنوان‌ها را در صفحه ویکی‌پدیا بخوانید . با REST، کلاینت‌ها اغلب می‌توانند یک هدر Accept را در درخواست خود به سرور ارسال کنند. لازم است که سرور بداند مشتری در چه قالبی انتظار دریافت پاسخ از آن را دارد. گزینه های فرمت های مختلف در لیست به اصطلاح نوع 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" : "+7 (191) 746-43-23"
}

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

بنابراین، ما به این موضوع نگاه کرده‌ایم که درخواست مشتری می‌تواند شامل چه مواردی باشد. اکنون چند نمونه از پرس و جوها را با توضیحات ارائه می دهیم

پاسخ ها

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

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

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

کدهای پاسخ HTTP

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

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

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

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

در اینجا می توانید اطلاعات بیشتری در مورد همه کدها بخوانید . قسمت 1: REST چیست قسمت 3: ایجاد یک سرویس RESTful در Spring Boot