Филдинг, изложенный в его диссертации :
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 не использует его и поэтому не имеет общей поддержки для него.
Клиент, разработанный для конечной точки SOAP A, скорее всего, также не будет взаимодействовать с другой конечной точкой SOAP B, управляемой другой компанией.Хотя можно утверждать, что веб-клиент также не знает, как обрабатывать каждый из различных типов медиа, браузеры обычно предоставляют механизм плагинов для загрузки таких знаний в клиент.Тип носителя в дополнение к тому, что он также стандартизирован, по крайней мере, должен быть, и поэтому может использоваться с большим количеством серверов (например, поддержка Flash).Еще одна проблема, с которой сталкиваются сервисы SOAP, заключается в том, что после того, как что-либо будет изменено в определении WSDL, клиенты, не знающие об обновлении, скорее всего перестанут работать с этой обновленной службой, пока код клиента не будет обновлен для работы с последней версией сгенерированных классов-заглушек..
Что касается формата XML, которым обмениваются в SOAP: Хотя технически вполне возможно, чтобы служба REST возвращала полезную нагрузку XML SOAP, сам формат не поддерживает HATEOAS, что является необходимостью, а не опцией.Как клиент должен делать дальнейшие выборы, основываясь на полученном ответе, просто на основе полученного контента, без каких-либо априорных знаний о самом API?
Надеюсь, вы видите, что в SOAP отсутствует поддержка кэширования, могут возникнуть проблемы смасштабируемость, а также приводит к тесной связи клиентов с фактическим API.Отсутствие поддержки HATEOAS в конверте / заголовке / теле сообщения SOAP также не позволяет клиентам свободно изучать API и, следовательно, автоматически адаптироваться к изменениям сервера.