Является ли служба Soap, работающая по протоколу HTTP, службой REST?

Надлежащие службы REST следуют архитектурным правилам, изложенным в главе пятой диссертации Роя Филдинга. Большинство людей ошибочно используют термин «REST API», когда они действительно означают «HTTP API». Безгражданство является необходимым, но не достаточным условием для API, чтобы соответствовать архитектурным рекомендациям REST.

Филдинг заявил в своей диссертации :

REST предоставляет набор архитектурных ограничений, которые при применении в целом подчеркивают масштабируемость взаимодействия компонентов, универсальность интерфейсов, независимость развертывание компонентов и промежуточных компонентов для уменьшения задержки взаимодействия, обеспечения безопасности и инкапсуляции устаревших систем.

Если вы сравните вышеупомянутые свойства с просмотром веб-страниц, вы обнаружите множество сходств между ними, поскольку Филдинг просто взял концепции, которые сделали Интернет таким успешным, и применил их к более общей области, что также должно позволять приложениям "путешествовать по сети".

Для того, чтобы по праву вызывать архитектуру REST, она должна поддерживать информативность, масштабируемость и кешируемость, а также соблюдать и придерживаться правил и семантики, изложенных в базовом транспортном протоколе, и обеспечивать использование четко определенных стандартов, таких как типы мультимедиа, имена отношений ссылок, операции HTTP, стандарты URI, ...

Информативность службы используется HATEOAS (или hate-us, как я это называю, как люди, подобные мне, которые увидеть преимущество в REST всегда нужно подчеркнуть этот ключевой термин, который, следовательно, также оказался в своем собственном мем ). Через HATEOAS клиент обслуживается сервером со всеми доступными «действиями», которые клиент может выполнить из текущего «состояния», в котором находится клиент. «Действие» - это просто ссылка с сопровождающим именем отношения ссылки, которое клиент может используйте, чтобы определить, когда лучше всего вызывать этот URI. Тип носителя, для которого был возвращен ответ, может определять, что делать с такими ссылками. HTML, т.е. утверждает, что при нажатии на ссылку запускается запрос GET и содержимое ссылки загружается либо в текущей панели, либо в новой вкладке, в зависимости от аргументов, которые имеет ссылка. Другие медиа-типы могут определять что-то похожее или совсем другое. Тем не менее, общий девиз: «Продолжай исследовать». Таким образом, модель взаимодействия в архитектуре REST лучше всего спроектирована как доступность и конечный автомат , в то время как реальный сервис должен больше походить на подход веб-сайта, где сервер учит клиента, то есть как должен выглядеть запрос. как и куда отправить запрос (аналог HTML форм).

Поскольку множество веб-страниц более или менее статично и большинство запросов ориентированы на поиск, сеть в значительной степени полагается на кэширование. То же самое обычно ожидается и от API REST, отсюда и жесткие требования к кешируемости, так как это может значительно снизить нагрузку на серверы при наличии надлежащего кеширования.

Сохраняя состояние клиента вдали от серверов, это также позволяет добавлять новые копии службы на новые серверы, расположенные за балансировщиком нагрузки или новыми регионами, и, таким образом, увеличивать масштабируемость. Клиенту обычно не важно, откуда он получает данные, поэтому сервер может просто вернуть URI, указывающий на клон, а не на себя.

С другой стороны, SOAP - это RPC, подобно удаленному вызову методов Java (RMI) или CORBA, где у вас есть собственный язык определения интерфейса (IDL) для генерации заглушки на стороне клиента, который содержит реальную логику того, как преобразовать определенные объекты в потоки байтов и как отправить их по проводам, где вы вызываете определенные методы.

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

Клиент, разработанный для конечной точки A SOAP, скорее всего, также не будет взаимодействовать с другой конечной точкой B SOAP, управляемой другой компанией. Хотя можно утверждать, что веб-клиент также не знает, как обрабатывать каждый из различных типов медиа, браузеры обычно предоставляют механизм плагинов для загрузки таких знаний в клиент. Тип носителя в дополнение к этому также стандартизирован, по крайней мере, должен быть, и, следовательно, может использоваться с большим количеством серверов (например, поддержка Flash, т. Е.). Еще одна проблема, с которой сталкиваются сервисы SOAP, заключается в том, что после того, как что-либо будет изменено в определении WSDL, клиенты, не знающие об обновлении, скорее всего перестанут работать с этой обновленной службой, пока код клиента не будет обновлен для работы с последней версией сгенерированных классов-заглушек .

Что касается формата XML, которым обмениваются в SOAP: Хотя технически вполне возможно, чтобы служба REST возвращала полезную нагрузку XML SOAP, сам формат не поддерживает HATEOAS, что является необходимостью, а не опцией. Как клиент должен делать дальнейшие выборы, основываясь на полученном ответе, просто на основе полученного контента, без априорного знания самого API?

Я надеюсь, вы видите, что в SOAP отсутствует поддержка кэширования, могут возникнуть проблемы с масштабируемость, а также приводит к тесной связи клиентов с фактическим API. Отсутствие поддержки HATEOAS в конверте / заголовке / теле сообщения SOAP также не позволяет клиентам свободно изучать API и, таким образом, автоматически адаптироваться к изменениям сервера.