[email protected]

Опровержение:
1) Част 1 е теоретична, може да бъде скучна:);
2) ако сте срещали и сте работили с HTTP протокола преди (знаете как работи, формата на заявката/отговора), не би трябвало да имате проблеми с разбирането на REST. Ако не сте сигурни, препоръчвам първо да прочетете
за HTTP в Wikipedia.

От wikipedia: ПОЧИВКА (Reпрезентационен СТейт тransfer) - архитектурен стил на взаимодействие на компонентите на разпределено приложение в мрежа.

За уеб услуги или приложни програмни интерфейси (API), изградени с мисълта REST (т.е. без да се нарушават наложените от тях ограничения), използвайте термина „ПОЧИСТЕН“.

REST е доста често срещан начин за взаимодействие между клиентски приложения и услуги в Интернет. Обикновено се нарича услуга, написана с отчитане на ограниченията и правилата REST ПОЧИВКА.

Следното е много важно: REST НЕ е протокол или стандарт.
За разлика от SOAP-базирани уеб услуги, няма одобрен или официално приет стандарт за RESTful услуги. REST е архитектура, докато SOAP е протокол.

Т.е. REST е набор от принципи и ограничения на взаимодействието клиент-сървър в Интернет, използвайки съществуващи стандарти (HTTP протокол, стандарт за изграждане на URL адреси, JSON и XML формати на данни) по време на взаимодействие.

В REST има шест основни ограничения:

1) Модел на взаимодействие клиент-сървър.

По-просто казано, необходимо е да се отделят изискванията и желанията на клиента/потребителя от възможностите и логиката на услугата.

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

Трябва да изградите логиката на вашето приложение въз основа на всеки потребител, като осигурите максимално възможния избор на параметри "по милост" на клиентското приложение.

2) Липса на държава.

Според REST услугата не съхранява резултатите от предишната операция. Тоест ние работим на принципа „попита-отговори-забрави“. 🙂

3) Кеширане.

Въпросът е, че двойка заявка-отговор може да бъде маркирана като кеширана и съхранена от страна на потребителя. Можете да направите аналогия с кеширането на уеб страници - след като го изтеглите, можете да го видите, без да се връщате към сървъра.
Ако обаче заявката е маркирана като „не кеширана“, при всяка нова заявка клиентът трябва да извика сървъра.

4) Еднородност на интерфейса.

Архитектурата REST определя, че всяка REST услуга трябва да се разбира без нейния разработчик. За да направите това, REST въвежда четири правила:

За да се отдели един ресурс (услуга) от друг, се използват заявки/връзки (URI).

Пример: информация за ISBN кода на книга в библиотеката - http://library.net/books/info/
ISBN разширение на книга - http://library.net/books/prolong/

Пример за неподходящо разделяне: http: // library/books/operation, където операцията и кодът на книгата трябва да са в тялото на заявката.

  • Манипулиране на ресурси чрез презентация.

С прости думи: ако сме получили метаданни за обект (от предишния пример - ISBN кодът на книгата), тогава можем да направим всяка операция от API с този обект.

Всяко съобщение съдържа достатъчно информация, за да се разбере как да се борави с него. Това включва както техническата обработка (например връщане на типа съдържание на отговора в HTTP заглавката), така и семантичната част на съобщението.

  • Хипермедия като начин за определяне на състоянието на приложението.

Архитектурата REST предполага, че клиентът трябва да третира услугата като хипертекстов документ. Тоест първото повикване преминава през известна входна точка към API, по-нататъшните действия се определят от информацията, която API изпраща в отговорите.

Клиентът не трябва да знае дали работи с крайна точка или с верига/йерархия от сървъри. Тоест, REST предоставя възможност за клъстер/разпределена работа на сървърната част, но в същото време за клиента услугата трябва да остане неразделна и да не изисква допълнителни данни/действия от клиента.

6) Код при поискване (по избор ограничение).

Тук архитектът REST предложи следното - при поискване услугата трябва да предостави изпълним код под формата на аплет или скрипт за изпълнение от страна на клиента. На практика не се използва на практика.

От гледна точка на потребителя, RESTful услугите са мрежови ресурси, които могат да бъдат всичко, което може да бъде именувано и представено.

Услугите се описват. Е, или се опитват:), но колкото по-логична и разбираема е системата за именуване (url), толкова по-удобно е да се работи с API.
Следователно api/books/get/ISBN/2-266-11156 е по-добър и по-ясен от гледна точка на клиента от/api? Obj = books & func = get & search = ISBN & number = 2-266-11156

Пример: Използвайки REST API, намерете книга на url api/books/get/ISBN/2-266-11156. В отговор на това услугата изпраща блок с информация, съдържащ елемент на невръзка, съдържащ връзката api/books/info/2-266-11156.

Взаимодействието с ресурси се осъществява чрез извикване на URL адреса на ресурса и стандартните HTTP команди (GET, POST, PUT и DELETE). Тези операции обикновено съответстват на операции върху обект, като това:

Услугата също изпраща отговора като HTTP код за връщане, например:

Всъщност HTTP има значително повече кодове за връщане (wiki - HTTP кодове). Също така, допълнителни данни за грешката могат да бъдат предадени в тялото на отговора.

Форматът на данните, предавани между клиента и услугата, се определя с помощта на HTTP заглавката - параметър Content-Type на типа съдържание. Обикновено това е JSON или XML, но може да бъде различно (например JPG, PNG - за услуга за графична обработка).

JSON срещу XML

За професионалисти, работещи със SAP PI/PO, XML е практически втори роден език. 🙂 JSON практически не се използва в света на SAP, така че ще обърна малко внимание на тази тема.

Основните разлики са:
JSON е по-компактен (JSON данните са по-малки от XML);
JSON е по-бърз при четене/прехвърляне на данни;
JSON позволява променливост на типове/структури (например в JSON схемата са разрешени елементи от един от няколко типа - в схемата за данни можете да определите, че елементът на цената може да бъде текст или може да бъде структура от два елемента) . След като свикне със строгостта на XML, променливостта на JSON е трудна за разбиране и приемане. 🙂

Използване на REST API

В момента почти всеки голям интернет ресурс има свой собствен REST API:

Следователно добрият интегратор трябва да може да работи с тях. Разработчиците на SAP взеха това предвид и пуснаха адаптер към SAP Process Integration за поддръжка на REST .

Но как да работя с него - ще бъде в следващата поредица. 🙂

След навигация

Една мисъл за „ПОЧИВКА“ не е свързана с „почивка“.
Част първа: какво е REST архитектура? "

Ура, появяват се нови статии 🙂 Очаквам втората част.