Я не могу создать четкое изображение, почему и когда использовать УСПОКОИТЕЛЬНЫЕ сервисы? [дубликат]
5 ответов
Это достойный вопрос, на который краткий ответ не отвечает. Забывая о том факте, что большинство людей могут быть более знакомы с SOAP, чем с REST, я думаю, что здесь есть несколько ключевых моментов:
Прежде всего, я бы предложил использовать REST везде, где это естественно. Если ваши основные сценарии использования включают чтение и обновление атомов данных («ресурсов»), REST обеспечивает более легкий, понятный и простой подход к доступу к данным. Кроме того, с REST часто проще создавать действительно тонкие клиенты (мобильные устройства, JavaScript, даже сценарии оболочки).
Например: если ваша модель данных полностью посвящена клиентам, а ваши основные операции включают чтение клиентов и обратную запись изменений, REST подойдет. Использование HTTP-протоколов GET / POST / PUT / DELETE - отличный способ сделать протокол легко обнаруживаемым и простым в использовании даже для тех, кто плохо знаком с вашим приложением.
Это, однако, подводит нас ко второму пункту.
Что делать, если вам нужно предложить веб-API с возможностями запросов? Например, типичным сценарием может быть «Получите мне 5 самых новых клиентов». В этом сценарии чистый REST мало что дает с точки зрения обнаружения API. Войдите в OData (www.odata.org), и вы снова катаетесь; с этой точки зрения синтаксис запросов на основе OData URI добавляет немного хорошо известной абстракции по сравнению с обычной чрезвычайно упрощенной адресацией служб REST на основе идентификаторов.
Но есть аспекты, которые довольно сложно представить в терминах REST. Пункт третий: если вы не можете достаточно чисто смоделировать его, подумайте о SOA.
Например, если обычный сценарий использования включает в себя переход клиентов между этапами рабочего процесса (скажем, «новый клиент», «запрос кредита получен», «кредит утвержден»), моделирование таких этапов с помощью REST может оказаться сложным.Должны ли различные этапы быть представлены только как значение атрибута в сущности? Или, возможно, следует смоделировать различные этапы как контейнеры, в которых лежат клиенты? Если это атрибут, всегда ли вы хотите выполнять полную PUT при его обновлении? Стоит ли вам использовать собственный HTTP-глагол («APPROVE http: // mysite / customers / contoso HTTP / 1.0»)?
Это правильные вопросы, на которые нет универсальных ответов. В REST можно смоделировать все, но в какой-то момент абстракция ломается настолько, что теряются многие преимущества REST для человека (открываемость, простота понимания). Конечно, технические преимущества (как и все достоинства уровня HTTP) все же можно получить, но в большинстве случаев они все равно не являются решающим аргументом.
И, наконец, в-четвертых, есть вещи, которые модель SOA просто великолепна. Возможно, наиболее важным из них является транзакция. Хотя это довольно сложная общая проблема в мире WS- *, общие транзакции редко нужны и часто могут быть заменены достаточно простыми атомарными операциями.
Например, рассмотрим сценарий, в котором вы хотите создать операцию, которая позволяет объединить двух клиентов и все их покупки под одной учетной записью. Конечно, все это должно происходить или не происходить; типичный сценарий транзакции. Моделирование этого в REST требует нетривиальных усилий. Для такого специализированного сценария, как этот, простой подход SOA будет заключаться в создании одной операции (MergeCustomers), которая реализует транзакцию внутренне.
Для более сложных сценариев стек WS- * предоставляет средства, недоступные в мире REST (включая WS-Transaction, WS-Security и многое другое). Хотя большинству API-интерфейсов ничего из этого не требуется (или лучше реализовать их более простым способом), я не думаю, что стоит переписывать все это только для 100% REST.
Взгляните на лучшее из обоих миров. Для подавляющего большинства сценариев вполне приемлемо иметь базовый CRUD в REST и обеспечивать несколько специализированных операций в SOA .
Кроме того, эти API-интерфейсы могут быть разработаны для совместной работы. Например, что должна вернуть операция MergeCustomers на основе SOA? Он может вернуть сериализованную копию объединенного клиента, но в большинстве случаев я бы предпочел вернуть URI ресурса REST, который является недавно объединенным клиентом. Таким образом, у вас всегда будет единое представление о клиенте, даже если SOA потребуется для специализированных сценариев.
Предыдущий подход имеет недостаток, заключающийся в том, что он требует клиентской поддержки как для REST, так и для SOA. Однако это редко бывает реальной проблемой (не считая чисто архитектурной точки зрения). Простейшие клиенты обычно имеют возможности REST по самому определению наличия стека HTTP, и они редко выполняют более сложные операции.
Конечно, ваш пробег может отличаться. Потребности вашего приложения (и его клиентов), локальные политики и требования обратной совместимости часто, кажется, доминируют в этих обсуждениях заранее, поэтому обсуждение REST и SOA редко бывает чисто техническим.
Android (мобильная ОС) не поддерживает SOAP. Службы RESTful лучше подходят, когда целью являются мобильные устройства.
Я лично предпочитаю службы RESTful в большинстве случаев, поскольку они более легкие, их легче отлаживать и интегрировать (если вы не используете генератор кода для SOAP).
Один момент, о котором не упоминалось, - это накладные расходы. В недавнем проекте REST, над которым я работал, требовалась передача файлов с разрешенными элементами размером до 2 ГБ. Если бы он был реализован как сервис SOAP, это было бы автоматическое увеличение данных на 30% + из-за кодирования. Накладные расходы службы REST - это все заголовки, остальное - прямые данные.
Вечный вопрос! SOAP против REST ....
SOAP великолепен, потому что он промышленно развит, сервисы самоописываются в машиночитаемом и интерпретируемом виде, например ваш компьютер может читать, понимать службу SOAP и создавать для нее клиента. SOAP великолепен, потому что это методы и все данные, которые он когда-либо будет передавать, подробно описаны и определены. Но SOAP немного тяжелый - для его поддержки требуется много инфраструктуры. SOAP также в основном ориентирован на методы, например вы определяете свои службы с помощью того, какие методы могут выполняться в службе.
REST намного легче - он использует только установленные протокол и процедуры HTTP, поэтому любое устройство, имеющее стек HTTP (а в настоящее время его нет), может получить доступ к службе REST. Никакой тяжелой работы с SOAP не требуется. REST также более ориентирован на ресурсы , , напримервы думаете о ресурсах, коллекциях ресурсов и их свойствах и о том, как с ними работать (так что вы в основном возвращаетесь к основной функции создания, чтения, обновления, удаления). REST в настоящее время не имеет машиночитаемого описания службы, поэтому вам остается либо попробовать и посмотреть, либо вам понадобится документация от поставщика услуг, чтобы узнать, какие ресурсы у вас есть.
Мой личный итог: если вы хотите предоставить доступ к некоторым коллекциям данных и охват (возможность доступа к ним с любого устройства) и простота использования более важны, чем надежность и другие функции корпоративного уровня, тогда REST это путь. Если вам нужны серьезные, четко определенные, хорошо задокументированные услуги для бизнеса, которые реализуют такие вещи, как надежность, поддержка транзакций и т. Д. - тогда вы определенно на правильном пути с SOAP.
Но я действительно не вижу подходов типа REST или SOAP - они будут отличными сценариями для обоих.
SOAP предоставит вам более богатый набор функций, и вы сможете создавать строго типизированные службы, в которых REST обычно более легок и легче запускается.
Edit: Если вы посмотрите на стандарты ws- *, там много всего http://www.soaspecs.com/ws.php . Однако инструменты разработки, такие как Visual Studio, значительно упрощают доступ ко многим из них. Обычно WS больше используется для разработки корпоративных типов SOA, в то время как REST используется для общедоступных API на веб-сайтах (по крайней мере, я так думаю).