#API #REST #интеграция

Вавилонская башня REST
Заметка о том, что люди в обыденной жизни называют RESTом, и как их понять.
Пока писал, нашел статью на схожую тему: https://habr.com/ru/post/319984/

На днях с интересом посмотрел доклад, где автор рассуждал о плюсах и минусах “REST-протокола”. В очередной раз вспомнил, что в термин REST человек может вкладывать примерно любой смысл. Усложняется история тем, что в сети полно статей и видосиков, дающих разные трактовки: одни говорят про правильные GET-POST-PUT, другие про JSON и XML, третьи вообще об архитектурных стилях рассуждают.

Вот моя версия Русско-Рестового словаря.

REST - это архитектурная концепция, которая рассказывает нам, как построить распределенную систему так, чтобы она была масштабируемой, производительной и со всех сторон успешной. Концепция включает в себя шесть принципов-ограничений, которым она должна удовлетворять. Возможно, глубокое изучение принципов никогда не понадобится аналитику, но часть из них стоит понять и осмыслить: модель client-server, stateless, кэширование – будет полезно не только при работе с REST-сервисами.

HATEOAS- идея гипермедиа, которую использует REST. Познакомиться можно на вики или тут. Встречается не так часто, но полезно для общего развития и философских дискуссий.

RESTful-сервис - сервис, удовлетворяющий принципам REST.

HTTP/1.1 - протокол передачи данных, на котором живет большая часть интернета. А вот REST протоколом не является.
Чтобы понять, как правильно использовать POST, PUT и статус коды, нужно читать спеку HTTP. Или для начала посмотреть статью на тему.

А теперь следим за руками. Несмотря на то, что в массовом сознании HTTP и REST неразлучны, REST никак не привязан к конкретному протоколу передачи данных. Можете спроектировать взаимодействия хоть поверх очередей, если ваши сервисы будут соответствовать принципам REST, то можно смело называть их RESTful-сервисами.
Но лучше об этом не говорить, т.к. собеседник может принять вас за сумасшедших. Да, для многих REST и HTTP почти синонимы.

Тогда что принято называть REST-сервисами в повседневной жизни? Здесь хочу обратиться к модели зрелости REST-сервисов Ричардсона. Он выделяет 4 уровня зрелости REST-сервисов:

Уровень 0. Мы берем в качестве протокола HTTP, но при этом игнорируем рекомендации по использованию HTTP-глаголов и именованию ресурсов aka endpoints. Часто в таких случаях используют POST с одним endpoint. Сюда можно отнести SOAP, XML-RPC, JSON-RPC и еще много чего.
Уровень 1. Начинаем правильно работать с ресурсами, но по-прежнему ограничиваемся одним HTTP-глаголом.
Уровень 2. Мы научились использовать HTTP-глаголы, статус коды и разделять endpoints так, как предусмотрено HTTP.
Уровень 3. Все то же самое, только дополнительно реализуем HATEOAS

Так вот, чаще всего REST-сервисами называют:
⁃ Сервис Уровня 0, который использует JSON. Так называемый JSON поверх HTTP, или JSON over HTTP
⁃ Сервис Уровня 2, т.е. правильное HTTP API

Кстати, многие считают, что REST-сервис - это обязательно JSON, XML использовать мы уже не можем. Хотя в концепции REST таких ограничений, конечно, нет.