Преглед на REST. Част 2: Комуникация между клиент и сървър

Преглед на REST. Част 1: Какво е REST? В тази част ще се потопим дълбоко в това How се осъществява комуникацията между клиент и сървър. По пътя ще разкриваме нови термини и ще ги обясняваме. За да сме сигурни, че всичко е ясно, ще анализираме комуникацията клиент-сървър, използвайки RESTful приложение като пример. Да предположим, че разработваме уеб приложение, което съхранява информация за клиентите и техните поръчки. С други думи, нашата система е в състояние да извършва операции с определени обекти: да ги създава, редактира и изтрива и да показва информация за тях. Тези субекти ще бъдат:

• клиенти (клиенти)
• поръчки (поръчки на клиенти)
• артикули (продукти)

В RESTful архитектура клиентите изпращат заявки до сървър за извличане or модифициране на данни, а след това сървърите изпращат на клиентите отговори на техните заявки.

Заявки

Клиентските заявки почти винаги се правят с помощта на HTTP протокола. Като цяло HTTP заявките се състоят от няколко компонента:

• HTTP метод
• заглавка
• URI
• тяло на заявката

По-долу ще разгледаме всеки компонент по-подробно.

URI и ресурси

Данните, които клиентите получават or променят чрез заявки, се наричат ​​ресурси. Комуникацията клиент-сървър е свързана с манипулиране на ресурси. В REST ресурсите са всичко, на което можете да дадете име. В известен смисъл те са като класове в Java. В Java можем да създадем клас за всичко. Така че в REST ресурсът може да бъде всичко: потребител, document, отчет, поръчка. Това може да бъде or абстракция на няHowъв обект, or нещо конкретно, например изображение, видео, анимация or PDF файл. В нашия пример имаме 3 ресурса:

• клиенти (клиенти)
• поръчки (поръчки на клиенти)
• артикули (продукти)

Клиентите изпращат заявки до местоположения на ресурси, известни като крайни точки. Казано просто, крайната точка е като address в мрежата. Гмуркайки се по-дълбоко, можем да кажем, че крайната точка е URI, т.е. поредица от знаци, която идентифицира абстрактен or физически ресурс. Унифициран идентификатор на ресурс (URI) Понякога крайна точка or URI се нарича път, което означава пътят към ресурс. За целите на тази статия ще използваме термина URI. Всеки конкретен ресурс трябва да има уникален URI. Разработчикът на сървъра е отговорен да гарантира, че всеки ресурс винаги има свой собствен URI. В нашия пример ние сме разработчиците, така че ще го направим Howто знаем. Точно Howто често е обичайно да се присвояват цифрови идентификатори като първични ключове в релационна база данни, всеки ресурс също има свой собствен идентификатор в REST. ИД на ресурса в REST често съвпада с ИД на записа в базата данни, която съхранява информация за ресурса. REST URI обикновено започват с формата на множествено число на съществително име, описващо няHowъв ресурс. Например, "

• /клиенти — URI на всички налични клиенти
• /customers/23 — URI на конкретен клиент, т.е. клиента с ID=23
• /customers/4 — URI на конкретен клиент, т.е. клиентът с ID=4.

Но това не е всичко. Можем да разширим URI чрез добавяне на поръчки:

• /customers/4/orders — URI на всички поръчки, напequalsи от клиент № 4
• /customers/1/orders/12 — URI на поръчка № 12, напequalsа от клиент № 1.

Ако продължим разширяването чрез добавяне на още продукти, получаваме:

• /customers/1/orders/12/items — URI на списъка с всички продукти в поръчка №12, напequals от клиент №1.

Докато добавяме нива на влагане, важното е да направим URI интуитивни.

HTTP метод

HTTP методът е поредица от произволни знаци (с изключение на контролни знаци и разделители), която показва основната операция, която се изпълнява върху ресурса. Има няколко общи HTTP метода. Ще изброим тези, които се използват най-често в RESTful услугите:

• GET — Вземете информация за конкретен ресурс (чрез неговия идентификатор) or за колекция от ресурси
• POST — Създаване на нов ресурс
• PUT — Промяна на ресурс (чрез неговия ID)
• DELETE — Изтриване на ресурс (чрез неговия ID)

Заглавки

Заявките, Howто и отговорите, съдържат HTTP заглавки. Те предават допълнителна информация относно заявката (or отговора). Заглавките са двойки ключ-стойност. Можете да видите списъка с най-често срещаните заглавки в Wikipedia . Що се отнася до REST, клиентите често изпращат заглавка „Приемам“ в заявки към сървъра. Този хедър е необходим, за да каже на сървъра в Howъв формат клиентът очаква да получи отговор. Различни формати са дадени в списък с типове MIME. MIME (Многофункционални разширения за интернет поща) е спецификация за codeиране на информация и форматиране на съобщения, така че да могат да бъдат изпращани по Интернет. Всеки тип MIME се състои от две части, разделени с наклонена черта — тип и подтип. Примери за MIME типове за различни типове файлове:

• текст — текст/обикновен, текст/css, текст/html
• изображение — изображение/png, изображение/jpeg, изображение/gif
• аудио — аудио/wav, аудио/mpeg
• видео — видео/mp4, видео/ogg
• приложение — приложение/json, приложение/pdf, приложение/xml, приложение/октет-поток

Например една заявка може да има заглавка като тази:

Accept:application/json

Тази заглавка казва на сървъра, че клиентът очаква да получи отговор във формат JSON.

Тяло на заявката

Това е съобщението, изпратено от клиента до сървъра. Дали заявката има тяло or не зависи от типа на HTTP заявката. Например заявките GET и DELETE обикновено не съдържат тяло на заявката. Но PUT и POST заявките могат - зависи само от целта на заявката. В края на краищата, за да получавате и/or изтривате данни с помощта на ID (който се предава в URL address), не е необходимо да изпращате допълнителни данни към сървъра. Но за да създадете нов ресурс (чрез POST заявка), трябва да изпратите ресурса. Същото важи и за модифициране на съществуващ ресурс. В REST тялото на заявката най-често се изпраща в XML or JSON формат. Форматът JSON е най-често срещаният. Да предположим, че искаме да изпратим заявка до сървъра, за да създадем нов ресурс. Ако не сте забравor, разгледахме примера на приложение, което управлява поръчките на клиентите. Да кажем, че искаме да създадем нов клиент. В нашия случай ние съхраняваме следната информация за клиента: име, имейл, телефонен номер. Тогава тялото на заявката може да бъде следният JSON:

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

Събиране на заявки

И така, проучихме Howво може да се съдържа в клиентска заявка. Сега ще дадем някои примери за заявки заедно с описания

Отговори

Нека кажем няколко думи за отговорите на сървъра. Отговорът обикновено се състои от следните части:

• code за отговор
• заглавки
• отговорно тяло

Като цяло заглавките на отговорите не се различават много от заглавките на заявките. Освен това някои заглавки се използват Howто в отговорите, така и в заявките. Мисля, че всичко е ясно и по отношение на тялото на заявката. Органът често връща информация, поискана от клиента. Информацията, върната в отговор на GET заявки, може също да бъде във формат JSON. Но последната част е малко по-интересна.

HTTP codeове за отговор

Нека разгледаме по-подробно HTTP codeовете за отговор. HTTP codeът на състоянието е част от първия ред на сървърния отговор на заявки, напequalsи чрез HTTP протокола. Това е цяло число, състоящо се от три десетични цифри. Първата цифра показва класа на codeа за състояние на отговора. Кодът на отговора обикновено е последван от обяснителна фраза на английски, разделена с интервал. Тази фраза е разбираема за хората причина за отговора. Примери:

• 201 Създаден
• 401 Неразрешено
• 507 Недостатъчно място за съхранение

Кодът на отговор съобщава на клиента резултата от заявката и му позволява да определи Howви действия да предприеме по-нататък. Кодовете за отговор са разделени на няколко класа or групи:

• 1XX — Информационен
• 2XX — Тези codeове показват, че заявката на клиента е получена и обработена успешно
• 3XX — Тези codeове информират клиента, че трябва да се направи допълнителна заявка, обикновено към различен URI, за да завърши успешно операцията
• 4XX — Грешка на клиента. Такива codeове могат да бъдат резултат от неправилно съставена заявка. Друг пример е добре познатият code „404 не е намерен“, който може да възникне, когато клиент поиска несъществуващ ресурс
• 5XX — Грешка в сървъра. Тези codeове се връщат на клиента, ако сървърът е отговорен за неуспеха на операцията

Преглед на REST. Част 3: Изграждане на RESTful услуга на Spring Boot