Чем отличаются REST и SOAP
Статьи и видеоролики на эту тему приводят меня в изумление. Тема раскрыта, но куда-то не туда...
Мнения примерно такие: SOAP-сервисы самодокументированные и в этом смысле лучше. Но SOAP всегда XML, а REST всегда JSON. А раз JSON компактнее и нагляднее, чем XML, то получается REST лучше, чем SOAP. Могут быть еще добавлены определения и технические особенности протоколов, которые новичкам и программистам пока не нужны. Либо бывает так: автор пишет, что он невозможный ГУРУ, использовал, все что есть, в том числе разную экзотику, ну то есть себя похвалил, а никакого совета не дал.
Что же на самом деле? XML обязателен для SOAP только в части протокольной оболочки (конверта), этим управлять невозможно. А параметры и ответ могут быть хоть в XML, хоть в JSON, хоть строками, хоть цифрами. В этом и прелесть. Но в целом, размер и время разбора пакета (из-за конверта) получается больше, поэтому там где это критично предпочтителен REST.
А еще REST - это фактически HTTP и в нем почти нет ничего лишнего. Правда, ключевое слово здесь "ПОЧТИ". Тут небольшое отступление...
Изначально, в эпоху динозавров, в HTTP-протоколе было два вида HTTP-запросов:
- GET - параметры передаются прямо в адресной строке браузера.
- POST - добавлено тело запроса для параметров, которые невозможно или некрасиво передавать в адресной строке (их много или они объемные).
То есть все просто и понятно. А потом зачем-то добавили новые виды: PUT, DELETE и еще разный зоопарк. Но основных все-таки четыре:
То есть в этом новом подходе GET превратился всего лишь в логическую команду ПОЛУЧИТЬ. И наступила путаница.
В итоге, при анализе различных современных REST API, которые написали профессионалы высокого уровня из известных компаний часто возникает недоумение:
- Для разных действий могут использоваться методы с одинаковым названием, но разным типом HTTP-запроса (POST, GET, PUT, DELETE). Казалось бы, это должно помогать разработчику при написании интеграции, но на самом деле приводит к ошибкам из-за невнимательности. Разные сущности все-таки лучше называть по разному.
- Параметры могут передаваться в строке запроса (которая когда-то была адресной строкой браузера), в заголовках и в теле. И часто невозможно уловить логику: один и тот же параметр в разных методах может быть в разных местах. Возможен даже POST-запрос с пустым телом {}. Почему он тогда не GET - непонятно.
- Наоборот, если передать тело (конечно же пустое {}) в GET-запрос, то одно API это проглатывает, а другое падает. Почему бы это не регламентировать в стандарте.
Получается, что если опустить особенности реализации и синтаксис подключения, REST и SOAP отличаются только способом передачи параметров. В SOAP все логично, а в REST - не очень. Поэтому мое текущее мнение такое: REST конечно современнее и компактнее, поэтому предпочтительнее, чем SOAP. А разработчикам надо просто повнимательнее относится к архитектуре своих сервисов. В частности, возможно было бы лучше, если все методы REST API были бы POST и все параметры только в теле запроса. Согласитесь, стандартное
POST CreateOrder
POST GetOrder
POST UpdateOrder
POST DeleteOrder
Ну или допустим, что вы будете делать, если хотите получить данные и соответственно решили использовать GET, но в качестве параметра вам необходимо передать массив (возможно большой массив). Признайтесь сами себе, что сделаете POST, но с очень недовольным выражением лица. Так и живем.