Почему и когда использовать службы RESTful?
Я знаю, как создать веб-сервис WCF. Но я не могу понять, когда использовать службу на основе SOAP и когда использовать службу RESTful. Я прочитал много статей о SOAP и REST, но все же у меня нет четкой картины о том, почему и когда использовать службы RESTful.
Какие конкретные точки можно легко решить между этими сервисами?
Это достойный вопрос, и тот, для которого короткий ответ не делает правосудия. Забыв о том, что большинство людей могут быть более знакомы с 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 редко находится на чистой технической основе.
Вечный вопрос! SOAP против REST....
SOAP отлично, потому что это промышленная сила, услуги самоописываются машинно-читаемым и -интерпретируемым способом, например. ваш компьютер может читать, понимать SOAP-сервис и создавать для него клиент. SOAP велик, потому что методы и все данные, которые он когда-либо будет проходить, описываются и определяются очень подробно. Но SOAP немного тяжелый - для его поддержки требуется много инфраструктуры. SOAP также в основном ориентирован на методы, например. вы определяете свои услуги с помощью того, что методы могут быть выполнены в службе.
REST гораздо более легкий - он использует только установленные HTTP-протоколы и процедуры, поэтому любое устройство, имеющее стек HTTP (а что нет, в наши дни), может получить доступ к службе REST, Нет необходимости в тяжелой обработке SOAP. REST также более ресурс -центрический, например. вы думаете о ресурсах, коллекциях ресурсов и их свойствах и о том, как справляться с ними (так что вы в основном возвращаетесь к основной функции создания, чтения, обновления, удаления). В настоящее время REST не имеет машинного машиночитаемого описания сервиса, поэтому вам также нужно попросить и посмотреть, или вам нужна документация от поставщика услуг, чтобы узнать, какие у вас ресурсы.
Моя личная нижняя строка: если вы хотите открыть некоторые коллекции данных и достичь (доступ к ней с любого устройства), а простота использования важнее надежности и других возможностей корпоративного уровня, тогда REST это путь. Если вам нужны серьезные бизнес-решения, четко определенные, хорошо документированные службы, которые реализуют такие вещи, как надежность, поддержка транзакций и т.д., То вы определенно находитесь на правильном пути с SOAP.
Но я действительно не вижу REST эксклюзивного или SOAP-подхода - они будут отличными сценариями для обоих.
SOAP предоставит вам более богатый набор функций, и вы сможете создавать строго типизированные сервисы, где REST обычно более легковесен и легче работать.
Редактирование: если вы посмотрите на стандарты ws- *, то будет много вещей http://www.soaspecs.com/ws.php. Средства разработки, такие как Visual Studio, очень облегчают доступ к многим из них. Обычно WS используется больше для разработки корпоративного SOA-типа, тогда как REST используется для публичного API на веб-сайтах (по крайней мере, это то, что я думаю).
Android (мобильная ОС) не поддерживает SOAP. Услуги RESTful намного лучше подходят, когда мобильными устройствами являются целевые объекты.
Я лично предпочитаю услуги RESTful в большинстве случаев, поскольку они более легкие, легче отлаживаются и интегрируются (если вы не используете генератор кода для SOAP).
Один момент, о котором не упоминалось, - накладные расходы. Недавний проект REST, над которым я работал, включал передачу файлов с предметами объемом до 2 ГБ. Если бы это было реализовано как SOAP-сервис, это было бы автоматическое 30% + увеличение данных из-за кодирования. Накладные расходы с помощью службы REST - все заголовки, остальные - прямые данные.