REST не е за - почивка

Опровержение:
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 въвежда четири правила:

---