WSDL по сравнению с за и против REST

Относительно WSDL (что означает «SOAP») как «тяжеловесного». Какое значение имеет тяжелое? Если набор инструментов делает за вас всю «тяжелую работу», тогда почему это имеет значение?

Мне еще никогда не приходилось использовать сложный REST API. Когда я это сделаю, я ожидаю, что мне понадобится WSDL, который мои инструменты с удовольствием преобразуют в набор прокси-классов, чтобы я мог просто вызывать то, что кажется методами. Вместо этого я подозреваю, что для того, чтобы использовать нетривиальный API на основе REST, необходимо будет вручную написать значительный объем «легковесного» кода.

Даже когда это все будет сделано, вы все равно будете иметь переводил удобочитаемую документацию в код со всем сопутствующим риском, что люди прочитают ее неправильно. Поскольку WSDL - это машиночитаемое описание службы, гораздо труднее "

REST is not a protocol; It's an architectural style. Or a paradigm if you want. That means that it's a lot looser defined that SOAP is. For basic CRUD, you can lean on standard protocols such as Atompub, but for most services you'll have more commands than just that.

As a consumer, SOAP can be a blessing or a curse, depending on the language support. Since SOAP is very much modelled on a strictly typed system, it works best with statically typed languages. For a dynamic language it can easily become crufty and superfluous. In addition, the client-library support isn't that good outside the world of Java and .NET

В защиту REST он строго следует принципам HTTP и адресации, например, операции чтения используют GET, операции обновления используют POST и т. Д. Я считаю, что это гораздо более чистый подход. Книга Oreilly RESTful Web Services объясняет это намного лучше, чем я. Если вы ее прочитаете, я думаю, вы предпочтете подход REST

Набор инструментов на стороне клиента будет одним. А знакомство с SOAP-сервисами другое. В наши дни все больше и больше сервисов переходят по маршруту RESTful, и тестирование таких сервисов может быть выполнено с помощью простых примеров cURL. Хотя не так уж и сложно реализовать оба метода и обеспечить максимально широкое использование со стороны клиентов.

Если вам нужно выбрать один, я бы предложил REST, это проще.

You can easily transition your WSDL-spewing WCF web components to other uses just by changing your configuration settings. You can go across HTTP and then also named pipes, tcp, custom protocols, etc without having to change your code. I believe WCF components may also be easier to set up for stuff like security, two-way calling, transactions, concurrency, etc.

REST pretty much limits you to HTTP (which is fine in many cases).

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

Я думаю, что интересно, что Многие плюсы и минусы, часто упоминаемые для SOAP и REST, имеют (IMO) очень мало общего с фактическими значениями или ограничениями этих двух технологий. Вероятно, наиболее цитируемым преимуществом REST является то, что он «легкий» или имеет тенденцию быть более «читабельным». На одном уровне это, безусловно, правда, REST имеет более низкий барьер для входа - требуется меньше структуры, чем SOAP (хотя я согласен с теми, кто сказал, что хорошие инструменты - это в значительной степени ответ здесь - слишком плохая часть инструментов SOAP - это довольно ужасно).

Однако, помимо первоначальной стоимости входа, Я думаю, что впечатление REST возникает из-за комбинации формы URL-адресов запросов и сложности данных, которыми обмениваются большинство служб REST. REST имеет тенденцию поощрять более простые, более удобочитаемые URL-адреса запросов, а данные также имеют тенденцию быть более удобоваримыми. Однако в какой степени они присущи REST и в какой степени они просто случайны. Более простая структура URL-адресов является прямым результатом архитектуры, но с таким же успехом может быть применена к службам на основе SOAP. Более удобоваримые данные, скорее всего, являются результатом отсутствия какой-либо определенной структуры. Это означает, что вам лучше поддерживать простые форматы данных, иначе вам придется много работать. Итак, дополнительная структура SOAP, которая должна быть преимуществом, на самом деле обеспечивает небрежный дизайн, и этот небрежный дизайн затем используется как опровержение технологии.

Поэтому я не уверен, что REST лучше, чем SOAP (или наоборот), для обмена структурированными данными между компьютерными системами, они просто другие. Я думаю, что приведенное выше сравнение REST и SOAP с динамической и статической типизацией является хорошим. Где дианмические языки имеют тенденцию к проблемам, так это в долгосрочном обслуживании и поддержании системы (и в долгосрочной перспективе я говорю не год или два, я говорю 5 или 10). Будет интересно посмотреть, столкнется ли REST со временем с теми же проблемами. Я склонен думать, что так оно и будет, поэтому, если бы я создавал распределенную систему обработки информации, я бы предпочел SOAP в качестве механизма связи (также из-за многоуровневости и гибкости протоколов передачи и приложений, которые он предоставляет, как было упомянуто выше)

. ] В других местах REST кажется более подходящим. Одним из основных примеров является AJAX между клиентом и его сервером (независимо от полезной нагрузки). Я не особо беспокоюсь о долговечности такого типа подключения, а простота использования и гибкость на первом месте. Точно так же, если мне нужен быстрый доступ к какой-то внешней службе, и я не думал, что буду заботиться о ремонтопригодности взаимодействия с течением времени (опять же, я предполагаю, что именно здесь REST в конечном итоге будет стоить мне больше, в одну сторону или другое), тогда я мог бы выбрать REST, чтобы я мог быстро входить и выходить.

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

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

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

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

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

Эти два протокола имеют очень разные применения в реальном мире.

SOAP (с использованием WSDL) - это тяжелый стандарт XML, который является сосредоточены на передаче документов. Преимущество этого состоит в том, что ваши запросы и ответы могут быть очень хорошо структурированы и даже могут использовать DTD. Обратной стороной является XML, и он очень подробный. Тем не мение, это хорошо, если у двух сторон должен быть строгий контракт (например, для межбанковского взаимодействия). SOAP также позволяет накладывать на документы такие вещи, как WS-Security. SOAP, как правило, не зависит от транспорта, что означает, что вам не обязательно использовать HTTP.

REST очень легкий и полагается на стандарт HTTP для своей работы. Это здорово - быстро запустить полезный веб-сервис. Если не нужен строгий Определение API, это путь. Большинство веб-сервисов попадают в эту категорию. Вы можете изменить версию своего API, чтобы обновления API не нарушали его работу для людей, использующих старые версии (если они указывают версию). REST по существу требует HTTP и не зависит от формата (это означает, что вы можете использовать XML, JSON, HTML и т. Д.).

Обычно я использую REST, потому что мне не нужны причудливые функции WS- *. SOAP хорош, если вы хотите, чтобы компьютеры понимали ваш веб-сервис с помощью WSDL. Спецификации REST обычно доступны только для чтения человеком.