В реалния живот обществата са подкрепени от мощни бойни сили и оръжия. Ако обществата използват тези способности както си искат, нещата вероятно ще излязат от ред. Следователно има много правила за това кога, защо, как и къде да ги използвате. Ние, софтуерните хора, живеем в един и същи свят. Софтуерът е подкрепен от огромен арсенал от мощни технологии. Ние създаваме правила и модели за това как да ги поставим в оптимални. Последствията от злоупотребата им варират от недоволни клиенти до мъртви клиенти. Обикновено, когато тези модели ограничават нас, софтуерните хора, ние изковаваме модела и технологията в нов с нови правила и модели. HTTP е мощна технология, а REST е модел, който гарантира, че се използва правилно за комуникация между процесите.
Започва с изпращане на заявка
API на услугата RESTful се взаимодейства с помощта на HTTP извиквания към URL адрес на услуга. Тези API са добре дефинирани и техният модел на отговор обикновено се очаква. API обикновено е изложен да работи върху нещо чрез четене, създаване, актуализиране или изтриване (CRUDing). Ние, софтуерните хора, сме свободни да решим какъв е обхватът на това нещо. Можем обаче да загубим доверието си в RESTfullness, ако този обхват или докосне неизследвани зони, или стане измамник и работи.
Зависи от целевите ресурси
Това е славният крайъгълен камък на REST. Това също е същността на това, което най-често се игнорира. REST въвежда идеята за ресурси. RESTful заявка е насочена към конкретен ресурс. Или ще поръчате турско кафе, или ще изстреляте това турско кафе с космически кораб до Луната. RESTful заявката е субективна за отделните ресурси. Ресурсът се идентифицира за всяка заявка. Например, обратно към нашата система за поръчка на турско кафе. Мога да се обадя на сервиза за кафе, за да направя поръчка за кафе. По-късно мога да проследя състоянието на моята поръчка за кафе, като предоставя идентификатора на тази поръчка. Мога да променя решението си и да отменя тази поръчка в полза на лате (не). Освен това мога да бъда щедър и да изпратя молба за промяна на състоянието му, за да го изстреля на Луната за извънземни като знак за цивилизация наблизо на планетата Земя. При всяко взаимодействие взаимодействам с ресурс.
Можете да надхитрите REST, като предоставите случай на употреба, когато не може да бъде покрит по RESTful начин. Това е лесно. В нашия случай обаче, например, ако се интересувам да получа по-голямата част от хронологията на поръчките си, тогава взаимодействам с ресурс, който ме представлява като клиент. да речем идентификатор на клиента. Ако искам да действам според всички поръчки в системата, това е сива зона. REST идва на помощ, като прави това. Получаването на такива огромни данни по такъв начин трябва да бъде оправдано. REST може да не е отговорът на такива случаи на употреба (създаване или стрийминг на събития обикновено се отнасят до такива случаи на употреба). Разбира се, реалността е по-нюансирана. Всеки случай на употреба в тази област трябва да се проучи внимателно
REST също е свързан с операции
REST ни предоставя 5 глагола, за да категоризираме намерението на заявката:
- GET: Прочетете данни за ресурс
- POST: Създайте нов ресурс
- PUT: Актуализиране на ресурс
- КОРЕКЦИЯ: актуализация на ресурсите за придирчивост
- ИЗТРИВАНЕ: Изтриване на ресурса
Някои от нас може да започнат да изключват масите, когато бъдат принудени от тези глаголи. API са по-опростени, когато се използва POST за всички заявки, които променят данните. Например, изисква се разкриване на скрит смисъл, за да се прави разлика между промяна на поръчка или актуализиране на крайна точка на поръчка:
PUT https://localhost/coffeeservice/api/v1/orders/manageOrder
{ "servingDestination": "moon" }
vs
PATCH https://localhost/coffeeservice/api/v1/orders/manageOrder
{ "serveWithTurkishDelights": false }
Следователно, много от нас стават измамници и изрично адресират намерението на заявката в дефиницията на крайната точка, както следва:
https://localhost/coffeeservice/api/v1/orders/updateOrderDestination
и
https://localhost/coffeeservice/api/v1/orders/changeOrderSpecials
Последното е анти-модел. Ако това е начинът, по който актуализирате ресурсите си, тогава вашата услуга не е RESTful. Ако зависи от мен да преценя, бих казал, че това е сива зона. Ние, софтуеристите, търсим ясни дефиниции. Въпреки това можем да го изчистим, като предоставим пълния език, като изложим намерението на полезния товар.
Клиентите са взискателни, искат да актуализират много неща
Точно така, искам да актуализирам кафето си и искам да актуализирам информацията за кредитната си карта. Това са две различни актуализации. глаголите са едномерна операционна повърхност. Въпреки това, заедно с ресурсния подход, това би било възможно. Първият ресурс е моята поръчка, докато последният е информацията за моя профил.
Разкриване на API (контроли за хипермедия)
Правилният термин за това е хипермедийни контроли (както е описано в книгата REST на практика — Хипермедия и системна архитектура), което се отнася до грозния акроним HATEOAS (Hypertext As the Engine of Application State). Целта е при създаване на ресурс услугата да отговори с възможните опции за прилагане към него. Например, когато поръчката за кафе е изпратена, услугата отговаря с крайни точки, които трябва да бъдат извикани, за да отмени поръчката или да я замени. Това може да бъде от полза само ако бъде проследено и изследвано. Лично аз обаче не смятам, че това е неясен начин за размисъл върху поддържаната функционалност на дадена услуга.
