Станция техобслуживания

Дополнительные сведения о REST

Джон Фландерс (Jon Flanders)

Содержание

Это лучше, REST и SOAP?
What about security? Isn't SOAP more secure than REST?
Как насчет операции?
What about interoperability? Не SOAP должен быть о взаимодействии? Isn't SOAP more interoperable than REST?
But what about metadata? Так что если REST является настолько совместимых — есть WSDL с REST; без WSDL, не удалось создать клиентский прокси для вызова службы. REST is hard to use.
Что делать, если хотите использовать транспорт, отличный от HTTP?
После эти сведения не вы указываете мне REST является хорошо подходит для приложений- и SOAP для корпоративных приложений?
Строка снизу

В двух последних столбцах я описаны основные принципы REST и говорил о предоставление и использование веб-каналы Web. В этом столбце я отвечу на ряд вопросов, которые часто поставляются при сделать презентации или проведение сеансов обучения на использование для создания приложений на основе службы REST.

Это лучше, REST и SOAP?

Это один из наиболее распространенных вопросов, получить о REST и это вероятно бы честным. REST и SOAP часто называется «Веб-служб»и один часто используется вместо другого, но они совершенно разные подходы. REST является архитектурный стиль для создания приложений клиент сервер. SOAP — это спецификация протокола для обмена данными между двумя конечными точками.

Сравнение REST стилем вызова (RPC) удаленной процедуры создания приложений клиент сервер может быть более точным. RPC — стиля (вместо протокол, который является SOAP) построения клиент сервер приложений, в котором прокси (обычно создается из метаданных) используется в адресное пространство клиента для взаимодействия с сервером и прокси-сервера интерфейса имитирует интерфейса на сервер. Хотя SOAP не требует стиле RPC, большинство современных toolkits SOAP направленную (по по крайней мере они умолчанию) с помощью RPC.

В отличие от RPC, REST отсутствует прокси генерируемые метаданных (см. следующий вопрос для получения дополнительных сведений), которой означает, что клиент меньше сочетании к службе. Кроме того поскольку REST основывается на семантику HTTP, можно кэшировать запросы данных (запросов GET). RPC системы обычно не имеют такой инфраструктуры (и даже при выполнении RPC через HTTP с использованием SOAP, ответах SOAP не кэшируются, поскольку SOAP использует команды HTTP POST, считается небезопасным). SOAP намеренно eschews HTTP, в частности, чтобы разрешить SOAP работают через другие протоколы, поэтому фактически немного disingenuous вызов служб, основанных на SOAP веб-служб.

Моей точки зрения является REST и SOAP может использоваться для реализации подобных функций, но в общем SOAP должны использоваться при необходимости конкретную возможность SOAP, и преимущества REST сделать обычно наилучшим вариантом в противном случае —.

Как насчет безопасности? SOAP не более безопасен, чем REST?

Этот вопрос касается один из моих peeves животных, поскольку ответ не очевидно. Несложно просто как обеспечить безопасность службы RESTful как обеспечить безопасность службы на основе SOAP. В большинстве случаев, включающие REST или SOAP системы безопасности является таким же: Некоторые форма проверки подлинности на основе HTTP плюс SSL (Secure Sockets LAYER). Хотя технически технология для защищенных диалогов по протоколу HTTP, теперь называется Transport Layer Security (TLS), SSL по-прежнему является наиболее часто используемые имя.

Что такое значение true, является, основанных на SOAP службы из-за дополнительных протоколов указанного в различных WS-* спецификации, выполняет поддержки шифрование на всем сообщение безопасности. Это означает, что при передаче сообщений SOAP из конечной точки к конечной конечной точки, через протоколы одинаковые или разные сообщение безопасности. Если приложению этой определенной функции SOAP и WS-* определенно является способом перехода. REST вероятно бы быть параметр здесь из-за неверной его на HTTP, и по существу вы бы разработке multiprotocol приложения. Я думаю, что тот факт, SOAP с WS-* безопасность на уровне сообщений позволяет шифрование на всем является источником заблуждение служб на основе SOAP, более безопасен, чем службы RESTful.

Другая область, в котором WS-* людей потратили массу времени и усилий недавно, федеративной безопасности. Простая идея федеративной идентификации является создание доверия между двумя компаниями, где прошедшие из одной компании может быть доверенным и считается проверенным другой компании без необходимости хранить сведения о проверке подлинности второй компании (имя пользователя и пароль, обычно). Различные WS-* спецификации имеют реализаций из всех основных поставщиков, и Майкрософт интеграции идеи в Active Directory через службы федерации Active Directory (ADFS).

В сфере федеративной безопасности WS-* ареной определенно имеет несколько стандартов чем RESTful ареной (и это вероятно всегда будет в случае), но существуют усилия для поддержки федеративной безопасности в мире REST. OpenID является один усилий. Шины служб .NET (часть Windows Azure) также содержит федеративной идентификации службы, которой работает только также с HTTP (и поэтому REST), не служб на основе SOAP.

Как насчет операции?

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

Вообще говоря Если требуется примерно транзакций в системе RESTful, создание нового ресурса. (Создание нового ресурса при запуске в неполадки RESTful системы обычно устранены большинства проблем). Имеется возможность ресурсом, именем транзакции. Когда клиент требуется сделать что-нибудь транзакций (таких как передача денег между двумя банковскими счетами), клиент создает транзакции ресурса, который определяет все правильные ресурсы, затронутых (в моем примере два банковских счетов) это ОТПРАВКУ фабрики транзакций URI. Клиент может выполнение обновлений, отправив PUT транзакции URI и закройте транзакции, отправив УДАЛЕНИЕ URI.

Это, само собой, требует некоторые объема кодирования вручную и явный контроль над системы, тогда как системы WS атомарных транзакции более автоматического поскольку (в случае использования Windows Communication Foundation) он остается привязанным к водопровода вашей среды выполнения.

Если системы абсолютно необходимы атомарные семантики транзакций между различными системами, атомарных WS транзакции вероятно — способ перейти. Использование распределенных транзакций таким способом может оказаться или смарт-так как она увеличивает связь между двумя системами и создает потенциальные проблемы, если не управление код на обоих концах. Но самое важное, что средство справа справа задания (после уже выяснить справа задания).

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

Как насчет совместимости? Не SOAP должен быть о взаимодействии? Не SOAP совместимых более чем REST?

Если определить взаимодействия как техническая возможность связи между двумя конечными точками отличающиеся я assert REST wins военную взаимодействия hands вниз.

Момента одну из точек движения за создание спецификации SOAP для создания совместимых способ связи между различными платформами и языков, многие люди будут удивлены, это утверждение. Но Забавные вещи произошло на способ широко взаимодействия: WS-* спецификации (и поставщиковреализации указанной спецификации) внесенные служб SOAP менее взаимодействия вместо более взаимодействия.

Проблемы в SOAP и WS-* ареной является большое количество различных стандартов (а версий каждого из этих стандартов) для выбора. И когда конкретного поставщика выбирает реализовать определенный стандарт, поставщика часто предоставляет реализацию, лишь незначительно отличается от другого поставщика (или другие). Это приводит к проблемы, когда необходимо пересекать границы поставщика (языков и операционной системы).

Разумеется, даже для использования SOAP требуется SOAP XML (веб-службы) на платформе, какие платформы большинство (но не всех) имеют сегодня. Затем нужно иметь дело с множество WS-* спецификации и выяснить, какие использовать (или неиспользования), а, влияющие на взаимодействие. Честно говоря, это тип беспорядок извлечение существует.

В терминах платформ REST имеет то преимущество из-за достаточно использовать REST стек HTTP (либо на клиентском компьютере или на сервере). Поскольку почти все платформы и устройство имеет, сегодня, я бы сказать, что REST имеет широкой взаимодействия. Учитывая, что мобильных устройств, домашние устройства, устройства POS, DVD-проигрыватели и ТВ все подключен к Интернету, есть больше и больше платформы для которой наличие полного SOAP XML (веб-службы) является невозможным или маловероятно. И даже при наличии средств SOAP для определенной платформы, вероятность ее работа с другой платформы реализации не 100 %.

Но как насчет метаданные? Так что если REST является настолько совместимых — есть WSDL с REST; без WSDL, не удалось создать клиентский прокси для вызова службы. REST трудно использовать.

Верно, что в мире REST отсутствует непосредственной поддержки для создания клиента из метаданных, созданные сервером стороны, при наличии в мире SOAP языка описания службы веб-(WSDL). Для получения такой поддержки в REST, один, параллельный спецификации, известные как WADL (язык описания веб-приложения) вносятся пара усилия. Второй – принудительной использование 2.0 WSDL для описания конечных точек RESTful. Я часто говорю REST является простой, но не всегда легко означает простой. SOAP является простым (из-за WSDL), но просто не всегда означает простой.

Да, использование WSDL делает создание прокси для службы основанных на SOAP, проще, чем написание кода для вызова службы RESTful. Но по-прежнему после создать что прокси необходимо узнать API. Ничего в WSDL указывает, какой метод вызова первой или второй или следует ли вызывать методы в определенном порядке вообще. Это все, что необходимо выяснить, после создания прокси-сервера и являются прототипов код для использования службы.

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

Кроме того out в wilds разработчика земли большинство служб упаковываются в нечто часто называется "сервисного агента"Это еще один уровень косвенного обращения для защиты клиентов от изменений в слое служб. Это может потребоваться REST или SOAP.

Другой точка является прокси, сгенерированный метаданные являются частью SOAP был предназначен для получение за пределами эры RPC именно локальных удаленных прозрачности. Считается, что концепцию наличие API-ИНТЕРФЕЙС на стороне клиента, соответствующий API на сервере был плохая идея, но точно происходящего большинства служб, основанных на SOAP. Также наличие прокси, сгенерированный метаданных в REST уменьшает шансы преимущества hyperlinking. С помощью гипертекста как обработчик состояния приложения (HATEOAS) является одним из ограничений REST и его использование требует более слабо API клиента.

Последней предстоит сделать том, как поддержка для REST становится более повсеместно построение клиентов будет проще и быстрее. Если взглянуть на начальный комплект REST Windows Communication Foundation (WCF) он включает средства, головки в этом направлении. Новый API HttpClient делает с использованием HTTP гораздо проще, чем с помощью API WebRequest и WebResponse .NET. Кроме того имеется новый Вставить как Serializable XML средство, которое позволяет скопировать фрагмент XML (скажем из документации конечной точки RESTful) и создать тип .NET, который может представлять что экземпляр XML в приложении. Это похоже на средства WCF действия автоматически для всей службы с WSDL. Со временем станет намного более сложных, дальнейшего упрощения возможностей клиента в WCF при использовании служб RESTful этих средств.

Что делать, если хотите использовать транспорт, отличный от HTTP?

Общие (отчасти Сомневающаяся) ответа от сообщества REST здесь является, "Перейти вперед, нет ничего, остановка." В действительности, однако REST в настоящее время привязан к HTTP, если только, поскольку большинство разработчикам и группам разработчиков не имеют времени для проектирования усилий, необходимо получить семантику REST для работы над скажем, TCP/IP.

Общих ответов технически отсутствуют, так как ничего не останавливается из реализации принципов REST через другие протоколы, но пока поставщиков добавить поддержку для этого, я нахожу сомнительного предложения для большинства.

После эти сведения не вы указываете мне REST является хорошо подходит для приложений- и SOAP для корпоративных приложений?

Если вы читали оставшейся части статьи, скорее всего можно представить я думаю, эта инструкция — обобщенный false. Часто услышать это ощущение после обсуждения отсутствие поддержки явные распределенной транзакции в REST против явной поддержки WS атомарных транзакции. Мои retort обычно является примерно "контейнер, XML (веб-службы) отсутствует поддержка распределенных транзакций, но выполняет означает XML (веб-службы) не полезен для предприятий?»

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

На самом деле, когда я думаю о корпоративных приложений часто думаю скорости и масштабируемости, масштабируемость, одним из основных различий между REST и SOAP. Службы SOAP — это гораздо труднее масштабирования чем RESTful служб, является, конечно, одной из причин, REST часто выбран в качестве архитектуры для служб, которые предоставляются через Интернет (таких как Facebook, MySpace, Twitter и т. д.).

Внутри предприятия приложениям также часто требуется также масштабирования. REST означает, что можно воспользоваться преимуществами кэширования HTTP и других возможностей, как условное GET, помогающих в масштабировании служб. Многие из этих методов не может использоваться с SOAP, поскольку SOAP использует только по протоколу HTTP POST.

Строка снизу

Надеюсь, что после считывания в этом столбце будут предполагается, ответ на "какой лучше, REST и SOAP?»является "Оно зависит." Архитектурный стиль REST и SOAP и WS-* протоколы иметь преимущества и недостатки при доходит до создания служб. Те из нас в camp RESTafarian (Да, необходимо предоставить полное раскрытие здесь: Я определенно в, camp) уверены, что в большинстве случаев службы REST предоставляет дополнительные преимущества от SOAP и WS-*. С другой стороны, SOAP и WS-* имеют некоторые функции, которые легко (и возможно) для реализации использования REST. При необходимости эти конкретные возможности требуется определенно использовать библиотеки и toolkits с этими функциями. Хотя этот столбец не был специально о WCF, одна удобная функция внедрению WCF является поддержка REST и SOAP/WS-*. Перемещение назад и вперед между двумя мирами становится проще, если имеется один программирования и модели среды выполнения для получения.

Вопросы и комментарии направляйте по адресу sstation@microsoft.com.

Джон Фландерс (Jon Flanders) - независимый консультант, лектор и инструктор в компании Pluralsight. Он специализируется на Windows Workflow Foundation, BizTalk Server и Windows Communication Foundation. Связаться с Джоном можно по адресу masteringbiztalk.com/blogs/jon.