REST کا جائزہ۔ حصہ 2: کلائنٹ اور سرور کے درمیان مواصلت

حصہ 1: REST کیا ہے اس حصے میں ہم اس بات کا بغور جائزہ لیں گے کہ کلائنٹ اور سرور کے درمیان بات چیت کیسے ہوتی ہے۔ راستے میں، ہم نئی شرائط ظاہر کریں گے اور ان کی وضاحت کریں گے۔ ہر چیز کو واضح کرنے کے لیے، ہم کچھ RESTful ایپلیکیشن کی مثال کا استعمال کرتے ہوئے کلائنٹ-سرور مواصلات کا تجزیہ کریں گے۔ ہم کہتے ہیں کہ ہم ایک ویب ایپلیکیشن تیار کر رہے ہیں جو صارفین اور ان کے آرڈرز کے بارے میں معلومات کو محفوظ کرنے کے قابل ہے۔ وہ. ہمارا نظام کچھ اداروں میں ہیرا پھیری کرنے کے قابل ہے: انہیں بنانا، ان میں ترمیم کرنا، انہیں حذف کرنا، اور ان کے بارے میں معلومات فراہم کرنا۔ یہ ادارے ہوں گے:

• کلائنٹس - کلائنٹس؛
• احکامات - گاہک کے احکامات؛
• اشیاء - سامان

REST فن تعمیر میں، کلائنٹ ڈیٹا حاصل کرنے یا اس میں ترمیم کرنے کے لیے سرور کو درخواستیں بھیجتے ہیں، اور سرور کلائنٹس کو ان کی درخواستوں کے جوابات بھیجتے ہیں۔

درخواستیں

کلائنٹ کی درخواستیں تقریبا ہمیشہ HTTP پر کی جاتی ہیں۔ عام طور پر، HTTP درخواستیں کئی اجزاء پر مشتمل ہوتی ہیں:

• HTTP طریقہ؛
• عنوان
• URI;
• جسم کی درخواست کریں.

ذیل میں ہم ہر جزو کے حصے کو مزید تفصیل سے دیکھیں گے۔

URI اور وسائل

وہ ڈیٹا جو کلائنٹ درخواستوں کے ذریعے حاصل کرتے ہیں یا اس میں ترمیم کرتے ہیں اسے وسائل کہا جاتا ہے۔ کلائنٹ سرور کے تعامل کی بنیاد وسائل کی ہیرا پھیری ہے۔ REST میں وسائل کچھ بھی ہیں جنہیں ایک نام دیا جا سکتا ہے۔ ایک لحاظ سے، یہ جاوا میں کلاسز کی طرح ہیں۔ جاوا میں ہم کسی بھی چیز کے لیے کلاس بنا سکتے ہیں۔ REST میں بھی ایسا ہی ہے - وسائل کچھ بھی ہو سکتا ہے: صارف، دستاویز، رپورٹ، آرڈر۔ یہ سب کچھ یا تو کسی ہستی کا خلاصہ ہو سکتا ہے یا کچھ ٹھوس، مثال کے طور پر، ایک فائل - تصویر، ویڈیو، اینیمیشن، پی ڈی ایف فائل۔ ہماری مثال کے طور پر، ہمارے پاس 3 وسائل ہیں:

• کلائنٹس - کلائنٹس؛
• احکامات - گاہک کے احکامات؛
• اشیاء - سامان

Клиенты отправляют requestы на так называемые эндпоинты, or же конечные точки (end point). Если говорить очень просто, эндпоинт — это что-то вроде address в сети. Если углубляться в суть, можно сказать, что эндпоинт — это URI: последовательность символов, идентифицирующая абстрактный or физический ресурс. Uniform Resource Identifier — унифицированный идентификатор ресурса. Иногда конечную точку, or URI называют путем (path) — путем до ресурса. В рамках этой статьи мы будем использовать термин URI. У каждого конкретного ресурса должен быть уникальный URI. Ответственность за то, чтобы у каждого ресурса всегда был свой URI лежит на плечах разработчика serverа. В нашем примере разработчики это мы, поэтому будем делать это так, How умеем. Подобно тому, How в реляционной базе данных часто принято первичным ключом задавать некоторый числовой ID, в REST у каждого ресурса есть свой ID. Часто бывает так, что ID ресурса в REST совпадает с ID записи в базе данных, в которой хранится информация о данном ресурсе. URI в REST принято начинать с множественной формы существительного, описывающего некоторый ресурс. Например, со слова clients. Далее через слэш указывают ID — идентификатор некоторого конкретного клиента. Примеры:

• /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 Method) — последовательность из любых символов, кроме управляющих и разделителей, которая указывает на основную операцию над ресурсом. Существует несколько общепринятых методов HTTP. Перечислим те из них, которые наиболее часто используются в RESTful сервисах:

• GET — служит для получения информации о конкретном ресурсе (через ID) либо о коллекции ресурсов;
• POST — служит для создания нового ресурса;
• PUT — служит для изменения ресурса (через ID);
• DELETE — служит для удаления ресурса (через ID).

Заголовки

В requestах, How собственно и в ответах, присутствуют HTTP заголовки. В них отправляется дополнительная информация о requestе (либо ответе). Заголовки представляют собой пары ключ-meaning. Список наиболее распространенных заголовков можешь почитать на странице в Википедии. Применительно к REST клиенты часто могут слать в requestе к serverу заголовок Accept. Он нужен, чтобы дать serverу понять, в Howом формате клиент ожидает получить от него ответ. Различные варианты форматов представлены в так называемом списке MIME-типов. MIME (англ. Multipurpose Internet Mail Extensions — многоцелевые расширения интернет-почты) — спецификация для codeирования информации и форматирования сообщений таким образом, чтобы их можно было пересылать по интернету. Каждый MIME тип состоит из двух частей, разделяемых слэшем — из типа и подтипа. Примеры MIME-типов для разных видов файлов:

• text — text/plain, text/css, text/html;
• 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.

Total, у requestа может присутствовать заголовок:

Accept:application/json

Данный заголовок говорит serverу, что клиент ожидает получить ответ в JSON формате.

Тело requestа

Пересылаемое клиентом сообщение на server. Есть у requestа тело or нет, зависит от типа HTTP requestа. Например, requestы GET и DELETE How правило не содержат ниHowого тела requestа. А вот PUT и POST могут содержать: тут все дело в функциональном назначении типа requestа. Ведь для получения данных и удаления по id (который передается в URL) не нужно слать на server дополнительные данные. А вот для создания нового ресурса (request POST) нужно этот ресурс передать. Также How и для модификации существующего ресурса. В REST для передачи тела requestа чаще всего используют форматы XML or JSON. Наиболее часто встречается JSON формат. Предположим, мы хотим отправить на server request, а в нем — создать новый ресурс. Если ты не забыл, в качестве примера мы рассматривали приложение, которое управляет заказами клиентов. Допустим, мы хотим создать нового клиента. В нашем случае мы храним следующую информацию о клиентах: Name Email Номер телефона Тогда телом такого requestа может быть следующий JSON:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}

Собираем requestы воедино

Итак, мы рассмотрели с тобой из чего может состоять клиентский request. Приведем теперь несколько примеров requestов с описанием

Ответы

Скажем пару слов об ответах serverа. Ответ How правило состоит из следующих частей:

• code ответа;
• заголовки;
• тело ответа.

В целом заголовки ответов мало чем отличаются от заголовков requestов. К тому же, некоторые заголовки используются и в ответах, и в requestах. С телом ответа тоже, думаю, все понятно. В теле часто возвращается информация которую requestил клиент. Может возвращаться в том же формате JSON информация на GET requestы. А вот последняя часть, немного более интересна.

Коды HTTP ответов

Рассмотрим подробнее codeы HTTP ответов. Приведем цитату из Википедии: Код состояния HTTP (англ. HTTP status code) — часть первой строки ответа serverа при requestах по протоколу HTTP. Он представляет собой целое число из трёх десятичных цифр. Первая цифра указывает на класс состояния. За codeом ответа обычно следует отделенная пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Примеры:

• 201 Created;
• 401 Unauthorized;
• 507 Insufficient Storage.

Клиент узнаёт по codeу ответа о результатах его requestа и определяет, Howие действия ему предпринимать дальше. Коды ответов подразделяются на несколько групп:

• 1ХХ — информационные;
• 2ХХ — информируют о случаях успешного принятия и обработки requestа клиента;
• 3ХХ — сообщают клиенту, что для успешного выполнения операции необходимо сделать другой request, How правило по другому URI;
• 4ХХ — ошибка клиента. Например, неправильно составленный request or же широко известный code 404 Not Found, которая может возникнуть, когда клиент запрашивает несуществующий ресурс;
• 5ХХ — ошибка serverа. returnsся клиенту в случае неудачного выполнения операции по вине serverа.

Более подробно обо всех codeах можно почитать тут. Часть 1: что такое REST Часть 3: создание RESTful сервиса на Spring Boot