REST для прожженых самоваров

Привет! Пользуюсь своим свободным временем по максимуму и вещаю вам с поезда. Кофе в Macdonals сегодня крайне восхитительно и я решил поделится с вами еще одной не самой большой, но крайне полезной статьей. Надеюсь никто не против :)
Аббревиатура REST выглядит как REpresentational State Transfer и должна хоть немного уже хотя бы на этом этапе прояснить вам что это такое.

По сути в современном интернете есть такой чудесный протокол как HTTP который является крайне универсальным. REST же — это архитектура передачи по HTTP состояний каких-либо ресурсов. REST != SOAP и не является протоколом. REST является архитектурным стилем. Понимать этом можно как угодноПод ресурсом будем понимать какую-то условную единицу информации.

Важно понимать, что передача информации по протоколу HTTP с ответом в виде JSON еще не означает что вы следуете архитектуре REST. Сама архитектура REST не привязана к конкретным технологиям и протоколам, но в реалиях современного Веб, построение RESTful API почти всегда подразумевает использование HTTP и каких-либо распространенных форматов представления ресурсов, например JSON, или, менее популярного сегодня, XML.

CRUD: Create, Read, Update, Delete — даю вам гарантию, что все это вы видели когда работали с базами данных. Какое отношение оно имеет к REST? Дело в том что в нашем сабже тоже есть 4 основных метода работы с данными. Предлагаю провести ассоциации:

Create в базе данных будет эквивалентен HttpPost в REST
Read (он же Select) в базе данных будет эквивалентен HttpGet в REST
UPDATE базе данных будет эквивалентен HttpPut в REST. (Для частичного обновления так же существует HttpPatch
DELETE базе данных будет эквивалентен HttpDelete в REST

Если приложение следует этим правилам, то приложение а) как минимум предсказуемое б) понятное как клиенту, так и серверу.
Самое важное это гарантировать что если вы шлете запрос типа READ, на сервере действительно произойдет HttpGet. И при ни в коем случае данные не будут удалены или созданы заново

Как вы могли понять из текста выше, клиент-серверная архитектура обязательна для того чтобы следовать REST. Такой подход логичен. упрощает масштабируемость и вообще всем от этого хорошо, поверьте :)

В моей статье о Web API на .NET Core я немного затрагивал что такое HTTP коды. Поэтому еще разок я вам советую их выучить — это лишним не будет. В архитектуре REST важно следовать этим кодам, их можно поделить на 4 остовых группы:

1XX — информационные. Например 101 код говорит о том, что происходит смена протоколов
2XX — успех. Код 200 говорит о том, что запрос принят и обработан без ошибок
3XX — редирект. 301 код вам скажет о том что ресурс перемещен (на постоянной основе). Маленький хинт: SendRedirect в MODX по умолчанию отдает код 302 (временно перемещен) до тех пор пока вы ему не укажете другое. Держите это в голове :)
4XX -ошибка на стороне клиента. Допустим 400 — код означающий что запрос составлен неправильно.
5XX — ошибка на стороне сервера. Например код 504 говорит о том что время на выполнение запроса вышло.

Теперь вы понимаете как удобно следовать REST? Ты как разработчик заранее и достоверно знаешь что происходит с твоим приложением и можешь заложить расширяемую и надежную структуру.

Спасибо за внимание! Надеюсь в совокупности с прошлой статьей у вас сложилось определенные знания.