Ответ 1
Это достойный вопрос, и тот, для которого короткий ответ не делает правосудия. Забыв о том, что большинство людей могут быть более знакомы с SOAP, чем REST, я думаю, что в этом есть несколько ключевых моментов:
В первую очередь, я предлагаю использовать REST, где бы он не соответствовал естественным образом. Если ваши основные сценарии использования включают чтение и обновление атомов данных ( "ресурсы" ), REST обеспечивает более легкий, доступный и простой подход к доступу к данным. Кроме того, создание действительно тонких клиентов (мобильных устройств, JavaScript, даже скриптов оболочки) часто проще с помощью REST.
Например: если ваша модель данных касается клиентов, и ваши основные операции включают в себя чтение клиентов и запись изменений, REST будет работать нормально. Использование протоколов GET/POST/PUT/DELETE HTTP - отличный способ сделать протокол очень доступным и простым в использовании, даже для тех, кто не знаком с вашим приложением.
Это, однако, приводит нас ко второй точке.
Что делать, если вам нужно предложить веб-API с возможностями запросов? Например, типичным сценарием может быть "Получите мне 5 новых клиентов". В этом случае чистый REST предоставляет мало возможностей для обнаружения API. Введите OData (www.odata.org), и вы снова катаетесь; с этой точки зрения синтаксис запросов на основе OData URI добавляет оттенок хорошо известной абстракции над обычной чрезвычайно упрощенной, основанной на ID адресами служб REST.
Но тогда есть аспекты, которые можно разумно представить в терминах REST. Пункт три: если вы не можете моделировать его достаточно чисто, рассмотрите SOA.
Например, если общий сценарий использования включает переход клиентов между этапами документооборота (например, "новый клиент", "полученный запрос кредита", "одобрение кредита" ), моделирование таких этапов с помощью REST может оказаться сложным. Должны ли разные этапы быть представлены как значение атрибута в сущности? Или, может быть, если бы различные этапы были смоделированы как контейнеры, в которых клиенты лежат? Если это атрибут, вы всегда хотите сделать полный PUT при его обновлении? Если вы, возможно, используете собственный HTTP-глагол ( "APPROVE http://mysite/customers/contoso HTTP/1.0" )?
Это действительные вопросы, на которые нет универсальных ответов. Все может быть смоделировано в REST, но в какой-то момент абстракция настолько разрушается, что большая часть преимуществ REST, ориентированных на человека (открытость, легкость понимания), теряется. Разумеется, технические преимущества (как и всякая добротность на уровне HTTP) все еще могут быть получены, но в большинстве реалий они все равно не являются критическим аргументом.
В-четвертых, и, наконец, есть вещи, которые модель SOA просто отличает. Возможно, наиболее важными из них являются транзакции. Хотя это и довольно сложная общая проблема в мире WS- *, общие транзакции редко необходимы и часто могут быть заменены достаточно простыми атомными операциями.
Например, рассмотрите сценарий, в котором вы хотите создать операцию, которая позволяет слияние двух клиентов и всех их покупок под одной учетной записью. Конечно, все это должно произойти или не произойдет; типичный сценарий транзакции. Моделирование этого в REST требует нетривиального усилия. Для специализированного сценария, такого как этот, простой подход SOA должен был бы создать одну операцию (MergeCustomers), которая внутренне реализует транзакцию.
Для более сложных сценариев WS- * stack предоставляет средства, которые не доступны в мире REST (включая WS-Transaction, WS-Security и еще много чего). В то время как большинству API ничего не нужно (или лучше реализовать их более простым способом), я не думаю, что стоит переписать все это, чтобы быть только 100% REST.
Посмотрите на лучшее из обоих миров. Для подавляющего большинства сценариев вполне приемлемо иметь базовый CRUD в REST и предоставлять несколько специализированных операций в SOA.
Кроме того, эти API могут быть разработаны для совместной работы. Например, как должна возвращаться операция MergeCustomers на основе SOA? Он может вернуть сериализованную копию объединенного клиента, но в большинстве случаев я бы предпочел вернуть URI ресурса REST, который является вновь объединенным клиентом. Таким образом, у вас всегда будет единое представление клиента, даже если бы SOA были необходимы для специализированных сценариев.
Предыдущий подход имеет тот недостаток, что он требует поддержки клиентов как для REST, так и для SOA. Однако это редко бывает реальной проблемой (кроме чисто архитектурной перспективы). Простейшие клиенты обычно имеют возможности REST по самому определению наличия HTTP-стека и редко выполняют более сложные операции.
Конечно, ваш пробег может отличаться. Потребности вашего приложения (и его клиентов), локальных политик и требований обратной совместимости часто, как представляется, доминируют в этих обсуждениях в forehand, поэтому обсуждение REST и SOA редко находится на чистой технической основе.