#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 таких ограничений, конечно, нет.
