January 21

Чем отличаются REST и SOAP

Статьи и видеоролики на эту тему приводят меня в изумление. Тема раскрыта, но куда-то не туда...

Мнения примерно такие: SOAP-сервисы самодокументированные и в этом смысле лучше. Но SOAP всегда XML, а REST всегда JSON. А раз JSON компактнее и нагляднее, чем XML, то получается REST лучше, чем SOAP. Могут быть еще добавлены определения и технические особенности протоколов, которые новичкам и программистам пока не нужны. Либо бывает так: автор пишет, что он невозможный ГУРУ, использовал, все что есть, в том числе разную экзотику, ну то есть себя похвалил, а никакого совета не дал.

Что же на самом деле? XML обязателен для SOAP только в части протокольной оболочки (конверта), этим управлять невозможно. А параметры и ответ могут быть хоть в XML, хоть в JSON, хоть строками, хоть цифрами. В этом и прелесть. Но в целом, размер и время разбора пакета (из-за конверта) получается больше, поэтому там где это критично предпочтителен REST.

Но REST - это фактически HTTP и дополнительно почти ничего не регламентировано. Тут небольшое отступление...

Изначально, в эпоху динозавров, в HTTP-протоколе было два вида HTTP-запросов:

  1. GET - параметры передаются прямо в адресной строке браузера.
  2. POST - добавлено тело запроса для параметров, которые невозможно или некрасиво передавать в адресной строке (их много или они объемные).

То есть все просто и понятно. А потом зачем-то добавили новые виды: PUT, DELETE и еще разный зоопарк. Но основных все-таки четыре:

  1. GET - Получение ресурса.
  2. POST - Создание ресурса.
  3. PUT - Обновление ресурса.
  4. DELETE - Удаление ресурса.

То есть в этом новом подходе GET превратился всего лишь в логическую команду ПОЛУЧИТЬ. И наступила путаница.

В итоге, при анализе различных современных REST API, которые написали профессионалы высокого уровня из известных компаний часто возникает недоумение:

  1. Для разных действий могут использоваться методы с одинаковым названием, но разным типом HTTP-запроса (POST, GET, PUT, DELETE). Казалось бы, это должно помогать разработчику при написании интеграции, но на самом деле приводит к ошибкам из-за невнимательности. Разные сущности все-таки лучше называть по разному.
  2. Параметры могут передаваться в строке запроса (которая когда-то была адресной строкой браузера), в заголовках и в теле. И часто невозможно уловить логику: один и тот же параметр в разных методах может быть в разных местах. Возможен даже POST-запрос с пустым телом {}. Почему он тогда не GET - непонятно.
  3. Наоборот, если передать тело (конечно же пустое {}) в GET-запрос, то одно API это проглатывает, а другое падает. Почему бы это не регламентировать в стандарте.

Получается, что если опустить особенности реализации и синтаксис подключения, REST и SOAP отличаются только способом передачи параметров. В SOAP все логично, а в REST - не очень. Поэтому мое текущее мнение такое: REST конечно современнее и хотя бы поэтому предпочтительнее, чем SOAP, а разработчикам надо просто повнимательнее относится к архитектуре своих сервисов. В частности было бы лучше, если бы все методы REST API были бы POST и все параметры только в теле запроса. Согласитесь, стандартное

POST Order
GET Order
PUT Order
DELETE Order

даже выглядят хуже, чем

POST CreateOrder
POST GetOrder
POST UpdateOrder
POST DeleteOrder

P.S. Критика моей писанины горячо приветствуется.

←20 | заметка 21 | 22→