вызов - Репрезентативная передача состояния(REST)и протокол простого доступа к объектам(SOAP)




безопасность простым (13)

Может ли кто-нибудь объяснить, что такое REST и что такое SOAP на простом английском? И как работают Web-сервисы?


Answers

SOAP и REST ссылаются на способы взаимодействия разных систем друг с другом.

REST делает это с использованием техник, которые напоминают связь, которую ваш браузер имеет с веб-серверами: используя GET для запроса веб-страницы, POSTing в поля формы и т. Д.

SOAP обеспечивает нечто подобное, но делает все путем отправки блоков XML взад и вперед. Другим ключевым компонентом SOAP является WSDL, который является документом XML, который описывает, какие функции и элементы данных поддерживаются. WSDL могут использоваться для программного «обнаружения», какие функции поддерживаются, а также для генерации программных кодов.


Как веб-сервисы SOAP, так и веб-сервисы REST могут также использовать протокол HTTP и другие протоколы (только для обозначения SOAP может быть базовым протоколом REST). Я буду говорить только о SOAP и REST, связанных с протоколом HTTP, потому что это их наиболее частое использование.

МЫЛО

SOAP («простой» протокол доступа к объекту) - это протокол (и стандарт W3C ). Он определяет, как создавать, отправлять и обрабатывать SOAP-сообщения.

  • Сообщения SOAP представляют собой XML-документы со специфической структурой: они содержат конверт, который содержит заголовок и раздел тела. Тело содержит фактические данные - мы хотим отправить - в формате XML. Существует два стиля кодирования , но мы обычно выбираем литерал , что означает, что наше приложение или его SOAP-драйвер выполняет сериализацию XML и неэтериализацию данных.

  • Сообщения SOAP перемещаются как HTTP-сообщения с подтипом SOAP + XML MIME. Эти HTTP-сообщения могут быть многочастными, поэтому мы можем прикрепить файлы к сообщениям SOAP.

  • Очевидно, мы используем архитектуру клиент-сервер, поэтому клиенты SOAP отправляют запросы веб-сайтам SOAP, а службы отправляют ответы клиентам. Большинство веб-сервисов используют WSDL-файл для описания службы. Файл WSDL содержит XML-схему (далее XSD) данных, которую мы хотим отправить, и привязку WSDL, которая определяет, как веб-сервис привязан к протоколу HTTP. Существует два стиля привязки : RPC и документ. По привязке стиля RPC тело SOAP содержит представление операционного вызова с параметрами (HTTP-запросы) или возвращаемыми значениями (HTTP-ответ). Параметры и возвращаемые значения проверяются на XSD. По привязке стиля документа тело SOAP содержит XML-документ, который проверяется на XSD. Я думаю, что стиль привязки документов лучше подходит для систем на основе событий, но я никогда не использовал этот стиль привязки. Стиль привязки RPC более распространен, поэтому большинство пользователей используют SOAP для целей XML / RPC для распределенных приложений. Веб-службы обычно находят друг друга, спрашивая UDDI сервер. Серверы UDDI являются реестрами, которые хранят местоположение веб-служб.

SOAP RPC

Таким образом, по моему мнению, наиболее распространенный SOAP-webservice использует стиль привязки RPC и стиль буквенного кодирования и обладает следующими свойствами:

  • Он отображает URL-адреса для операций.
  • Он отправляет сообщения с подтипом SOAP + XML MIME.
  • Он может иметь хранилище сеансов на стороне сервера, ограничений на это нет.
  • Драйверы клиента SOAP используют WSDL-файл службы для преобразования операций RPC в методы. Клиентское приложение взаимодействует с веб-сервисом SOAP, вызывая эти методы. Таким образом, большинство клиентов SOAP прерываются изменениями интерфейса (результирующие имена методов и / или изменения параметров).
  • Можно писать SOAP-клиенты, которые не будут разбиваться на изменения интерфейса с использованием RDF и находить операции по семантике, но семантический веб-сервис очень редок, и у них необязательно есть не прерывающий клиент (я думаю).

ОСТАЛЬНОЕ

REST (репрезентативная передача состояний) - это стиль архитектуры, который описан в dissertation Роя Филдинга. Это не касается протоколов, подобных SOAP. Он начинается с нулевого типа архитектуры, не имеющего ограничений, и определяет ограничения архитектуры REST один за другим. Люди используют термин RESTful для веб-сервисов, которые выполняют все ограничения REST, но, по словам Роя Филдинга, таких уровней, как REST, нет . Когда веб-служба не встречается с каждым единственным ограничением REST, это не веб-сервис REST.

Ограничения REST

  • Архитектура клиент-сервер - я думаю, эта часть знакома всем. Клиенты REST общаются с веб-службами REST, веб-службы поддерживают общее состояние данных - ресурс в дальнейшем и обслуживают клиентов.
  • Безгражданство - часть «государственного перевода» аббревиатуры: REST. Клиенты поддерживают состояние клиента (состояние сеанса / приложения), поэтому у служб не должно быть хранилища сеансов. Клиенты переносят соответствующую часть состояния клиента по каждому запросу в службы, которые отвечают соответствующей части состояния ресурса (поддерживаются ими). Поэтому запросы не имеют контекста, они всегда содержат необходимую информацию для их обработки. Например, по HTTP basic auth имя пользователя и пароль хранятся клиентом, и он отправляет их с каждым запросом, поэтому аутентификация происходит по каждому запросу. Это очень отличается от обычных веб-приложений, где аутентификация происходит только при входе в систему. Мы можем использовать любой механизм хранения данных на стороне клиента, например, в памяти (javascript), куки, localStorage и т. Д. ... чтобы сохранить некоторые части состояния клиента, если мы хотим. Причина ограничения безгражданства, что сервер хорошо масштабируется - даже при очень высокой нагрузке (миллионы пользователей) - когда ему не нужно поддерживать сеанс каждого отдельного клиента.
  • Кэш - ответ должен содержать информацию о том, что он может быть кэширован клиентом или нет. Это еще больше улучшает масштабируемость.
  • Равномерный интерфейс

    • Идентификация ресурсов - ресурс REST совпадает с ресурсом RDF . Согласно Филдингу, если вы можете что-то назвать, тогда это может быть ресурс, например: «текущая местная погода» может быть ресурсом, или «ваш мобильный телефон» может быть ресурсом, или «конкретный веб-документ» может быть ресурс. Чтобы определить ресурс, вы можете использовать идентификаторы ресурсов: URL и URN (например, номер ISBN по книгам ). Один идентификатор должен принадлежать только определенному ресурсу, но один ресурс может иметь много идентификаторов, которые мы часто используем, например, путем разбивки на страницы с URL-адресами, такими как https://example.com/api/v1/users?offset=50&count=25 , URL-адреса имеют некоторые specifications , например URL-адреса с одинаковыми адресами, но разные запросы не идентичны, или часть пути должна содержать иерархические данные URL-адреса, а часть запроса должна содержать неиерархические данные. Вот основные сведения о том, как создавать URL-адреса с помощью REST. Btw. структура URL имеет значение только для разработчиков услуг, настоящий клиент REST не относится к нему. Другой часто задаваемый вопрос - это управление версиями API, что является простым, потому что, согласно Fielding, единственная постоянная вещь по ресурсу - это семантика. Если семантика изменится, вы можете добавить новый номер версии. Вы можете использовать классическое 3-мерное управление версиями и добавить только основные номера в URL-адреса ( https://example.com/api/v1/ ). Таким образом, благодаря обратным совместимым изменениям ничего не происходит, с помощью изменений, не поддерживающих обратную совместимость, у вас будет семантика без обратной совместимости с новым корневым API https://example.com/api/v2/ . Таким образом, старые клиенты не будут ломаться, потому что они могут использовать https://example.com/api/v1/ со старой семантикой.
    • Манипулирование ресурсами через представления. Вы можете манипулировать данными, относящимися к ресурсам (состояние ресурса), отправив предполагаемое представление ресурсов - вместе с методом HTTP и идентификатором ресурса - в службу REST. Например, если вы хотите переименовать пользователя после вступления в брак, вы можете отправить запрос PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"} где {name: "Mrs Smith"} представляет собой JSON-представление предполагаемого состояния ресурса, другими словами: новое имя. Это происходит наоборот, служба отправляет представления ресурсов клиентам, чтобы изменить их состояния. Например, если мы хотим прочитать новое имя, мы можем отправить GET https://example.com/api/v1/users/1?fields="name" , в результате чего получится 200 ok, {name: "Mrs Smith"} Ответ 200 ok, {name: "Mrs Smith"} . Поэтому мы можем использовать это представление для изменения состояния клиента, например, мы можем отобразить «Добро пожаловать на нашу страницу, миссис Смит!» сообщение. Ресурс может иметь множество представлений в зависимости от идентификатора ресурса (URL) или заголовка accept мы отправили с запросом. Например, мы можем отправить изображение миссис Смит (возможно, не обнаженное), если запрашивается image/jpeg .
    • Самоописательные сообщения. Сообщения должны содержать информацию о том, как их обрабатывать. Например, метод URI и HTTP, заголовок типа контента, заголовки кеша, RDF, который описывает смысл данных и т. Д. Важно использовать стандартные методы. Важно знать specification HTTP-методов. Например, GET означает получение информации, идентифицируемой URL-адресом запроса, DELETE означает запрос сервера на удаление ресурса, идентифицированного данным URL-адресом, и так далее ... Коды состояния HTTP также имеют specification , например 200 означает успех, 201 означает новый ресурс был создан, 404 означает, что запрошенный ресурс не найден на сервере и т. д. Использование существующих стандартов является важной частью REST.
    • Hypermedia как двигатель состояния приложения (далее HATEOAS) - Hypermedia - это тип носителя, который может содержать гиперссылки. В Интернете мы следим за ссылками, описанными в формате гипермедиа (обычно HTML) - для достижения цели вместо ввода URL-адресов в панель addres. REST следует той же концепции, представления, отправленные службой, могут содержать гиперссылки. Мы используем эти гиперссылки для отправки запросов в службу. С ответом мы получаем данные (и, возможно, больше ссылок), которые мы можем использовать для создания нового состояния клиента, и так далее ... Вот почему гипермедиа - это двигатель состояния приложения (состояние клиента). Вы, наверное, задаетесь вопросом, как клиенты узнают и следуют гиперссылкам? У людей это довольно просто, мы читаем название ссылки, возможно, заполняем поля ввода, а после этого всего один клик. По машинам мы должны добавлять семантику к ссылкам с RDF (по JSON-LD с Hydra ) или с конкретными решениями гипермедиа (например, отношениями IANA и типами MIME, специфичными для поставщика , HAL+JSON ). Есть много машиночитаемых XML и JSON hypermedia , а их короткий список:

      Иногда трудно выбрать ...

  • Многоуровневая система. Мы можем использовать несколько уровней между клиентами и сервисами. Ни один из них не должен знать обо всех этих добавочных слоях, просто рядом с ним. Эти слои могут улучшить масштабируемость, применяя кеши и балансировку нагрузки, или они могут применять политики безопасности.
  • Код по запросу. Мы можем отправить обратно код, который расширяет функциональность клиента, например код JavaScript в браузере. Это единственное необязательное ограничение REST.

REST webservice - Различия в web-сервисах SOAP RPC

Таким образом, веб-сервис REST сильно отличается от веб-сервиса SOAP (с использованием стиля привязки RPC и стиля буквенного кодирования)

  • Он определяет единый интерфейс (в соответствии с протоколом).
  • Он сопоставляет URL-адреса ресурсам (а не операциям).
  • Он отправляет сообщения с любыми типами MIME (вместо SOAP + XML).
  • Он имеет связь без состояния и поэтому не может иметь хранилище сеансов на стороне сервера. (SOAP не имеет ограничений по этому поводу)
  • Он служит гипермедиа, и клиенты используют ссылки, содержащиеся в этой гипермедиа, чтобы запросить услугу. (SOAP RPC использует привязки операций, описанные в файле WSDL)
  • Он не прерывается изменениями URL только с помощью семантических изменений. (Клиенты SOAP RPC без использования семантики RDF, разбиваются на изменения файла WSDL.)
  • Он масштабируется лучше, чем веб-сервис SOAP из-за его поведения без гражданства.

и так далее...

Веб-сервис SOAP RPC не отвечает всем ограничениям REST:

  • архитектура клиент-сервер - всегда
  • без гражданства - possible
  • кеш - possible
  • единый интерфейс - никогда
  • многослойная система - possible
  • код по запросу (необязательно) - возможно

Мне нравится ответ Брайана Р. Бонди. Я просто хотел добавить, что Википедия дает четкое описание REST . Статья отличает его от SOAP.

REST - это обмен государственной информацией, максимально простой.

SOAP - это протокол сообщений, который использует XML.

Одна из основных причин, по которой многие люди перешли из SOAP в REST, заключается в том, что стандарты WS- * (называемые WS splat), связанные с веб-сервисами на основе SOAP, чрезвычайно сложны. См. wikipedia для получения списка спецификаций. Каждая из этих спецификаций очень сложна.

EDIT: по какой-то причине ссылки отображаются неправильно. REST = REST

WS- * = http://en.wikipedia.org/wiki/WS- *


Хорошо, я начну со второго вопроса: что такое веб-службы? , по очевидным причинам.

WebServices - это, по сути, фрагменты логики (которые можно смутно назвать методом), которые раскрывают определенные функции или данные. Клиент, реализующий (технически говорящий, потребляющий это слово), просто должен знать, какие параметры (ы) этот метод будет принимать, и тип данных, которые он собирается вернуть (если это вообще возможно).

Следующая ссылка говорит о REST & SOAP в предельно ясной форме.

REST против SOAP

Если вы также хотите знать, когда выбрать, что (REST или SOAP), тем больше причин пройти через это!


ОСТАЛЬНОЕ

Я понимаю, что основная идея REST чрезвычайно проста. Мы использовали веб-браузеры в течение многих лет, и мы видели, как легко, гибко, эффективно и т. Д. Веб-сайты. HTML-сайты используют гиперссылки и формы в качестве основного средства взаимодействия с пользователем. Их главная цель - позволить нам, клиентам, знать только те ссылки, которые мы можем использовать в текущем состоянии . И REST просто говорит: «Почему бы не использовать одни и те же принципы для управления компьютером, а не с человеческими клиентами через наше приложение?» Объедините это с мощью инфраструктуры WWW, и вы получите инструмент убийцы для создания больших распределенных приложений.

Другое возможное объяснение - это математически мыслящие люди. Каждое приложение в основном представляет собой конечный автомат с действиями бизнес-логики, являющимися переходами состояния. Идея REST состоит в том, чтобы отображать каждый переход на некоторый запрос на ресурс и предоставлять клиентам ссылки, представляющие переходы, доступные в текущем состоянии. Таким образом, он моделирует машину состояний через представления и ссылки. Вот почему он называется REpresentational State Transfer.

Удивительно, что все ответы, похоже, сосредоточены либо на формате сообщений, либо на использовании глаголов HTTP. Фактически, формат сообщения вообще не имеет значения, REST может использовать любой, при условии, что разработчик сервиса документирует его. HTTP-глаголы только делают сервис CRUD-сервисом, но еще не RESTful. То, что действительно превращает услугу в службу REST, - это гиперссылки (как гипермедийные элементы управления), встроенные в ответы сервера вместе с данными, и их количество должно быть достаточным для того, чтобы любой клиент мог выбрать следующее действие из этих ссылок.

К сожалению, довольно сложно найти правильную информацию о REST в Интернете, за исключением ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm . (Он тот, кто получил REST). Я бы рекомендовал книгу «REST in Practice», поскольку он дает всесторонний пошаговый учебник о том, как развиваться из SOAP в REST.

МЫЛО

Это одна из возможных форм архитектуры архитектуры RPC (удаленный вызов процедур). По сути, это просто технология, которая позволяет клиентам вызывать методы сервера через границы сервиса (сеть, процессы и т. Д.), Как если бы они вызывали локальные методы. Конечно, это на самом деле отличается от вызова локальных методов скоростью, надежностью и т. Д., Но идея такая простая.

По сравнению

Детали, такие как транспортные протоколы, форматы сообщений, xsd, wsdl и т. Д., Не имеют значения при сравнении любой формы RPC с REST. Основное различие заключается в том, что служба RPC изобретает велосипед, создавая собственный протокол приложения в API RPC с семантикой, которую только он знает. Поэтому все клиенты должны понимать этот протокол до использования службы, и никакая общая инфраструктура, такая как кеши, не может быть создана из-за собственной семантики всех запросов. Кроме того, API-интерфейсы RPC не предлагают, какие действия разрешены в текущем состоянии, это должно быть получено из дополнительной документации. REST, с другой стороны, подразумевает использование единообразных интерфейсов, позволяющих различным клиентам иметь некоторое понимание семантики API, а также средства управления гиперссылками (ссылки) для выделения доступных опций в каждом состоянии. Таким образом, он позволяет кэшировать ответы на услуги масштаба и корректно использовать API, без дополнительной документации.

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

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

Обновить

Мой опыт неожиданно показал, что разработка REST сложнее, чем SOAP. По крайней мере для .NET. Хотя существуют большие рамки, такие как ASP.NET Web API, нет инструментов, которые автоматически генерируют прокси-сервер на стороне клиента. Ничего подобного «Добавить ссылку на веб-службу» или «Добавить ссылку службы WCF». Нужно написать весь запрос на сериализацию и запрос на обслуживание. И человек, это много шаблонов. Я думаю, что для разработки REST требуется что-то похожее на WSDL и внедрение инструментов для каждой платформы разработки. На самом деле, похоже, есть хорошая основа: WADL или WSDL 2.0 , но ни один из стандартов, похоже, не поддерживается.

Обновление (январь 2016 г.)

Оказывается, теперь существует множество инструментов для определения REST API. Мои личные предпочтения в настоящее время - RAML .

Как работают веб-службы

Ну, это слишком широкий вопрос, потому что он зависит от архитектуры и технологий, используемых в конкретной веб-службе. Но в целом веб-служба - это просто приложение в Интернете, которое может принимать запросы от клиентов и возвращать ответы. Он открыт для Интернета, поэтому он является веб- сервисом, и он обычно доступен 24 часа в сутки, поэтому он является сервисом . Конечно, это решает некоторые проблемы (в противном случае, почему кто-либо когда-либо использовал веб-сервис) для своих клиентов.


Я думаю, что это так же просто, как я могу это объяснить. Пожалуйста, кто-нибудь может исправить меня или добавить к этому.

SOAP - это формат сообщений, используемый отключенными системами (например, через Интернет) для обмена информацией / данными. Это происходит с XML-сообщениями, идущими назад и вперед.

Веб-службы передают или получают сообщения SOAP. Они работают по-разному в зависимости от того, на каком языке они написаны.


Оба метода используются многими крупными игроками. Это вопрос предпочтения. Мое предпочтение - REST, потому что его проще использовать и понимать.

Простой протокол доступа к объектам (SOAP):

  • SOAP создает XML-протокол поверх HTTP или иногда TCP / IP.
  • SOAP описывает функции и типы данных.
  • SOAP является преемником XML-RPC и очень похож, но описывает стандартный способ общения.
  • Некоторые языки программирования имеют встроенную поддержку SOAP, вы обычно загружаете URL-адрес веб-службы, и вы можете вызывать его функции веб-службы без необходимости использования определенного кода.
  • Двоичные данные, которые отправляются, должны сначала кодироваться в формат, такой как base64, закодированный.
  • Имеет несколько протоколов и технологий, связанных с ним: WSDL, XSD, SOAP, WS-Addressing

Репрезентативная передача состояния (REST):

  • REST не обязательно должен быть HTTP, но большинство моих пунктов ниже будут иметь смещение HTTP.
  • REST очень легкий, он говорит, подождите минуту, нам не нужна вся эта сложность, созданная SOAP.
  • Обычно использует обычные HTTP-методы вместо большого формата XML, описывающего все. Например, для получения ресурса, использующего HTTP GET, для размещения ресурса на сервере используется HTTP PUT. Чтобы удалить ресурс на сервере, вы используете HTTP DELETE.
  • REST очень простой в том, что он использует методы HTTP GET, POST и PUT для обновления ресурсов на сервере.
  • REST обычно лучше всего использовать с Resource Oriented Architecture (ROA). В этом способе мышления все является ресурсом, и вы будете работать на этих ресурсах.
  • Пока ваш язык программирования имеет библиотеку HTTP, и большинство из них вы можете очень легко использовать протокол REST HTTP.
  • Двоичные данные или бинарные ресурсы могут быть доставлены по их просьбе.

Бесконечные дебаты по REST vs SOAP на google .

Мой любимый это . Обновление 27 ноября 2013: сайт Пола Прескода, похоже, отключен, и эта статья больше не доступна, копии можно найти на Wayback Machine или в формате PDF на CiteSeerX .


Это самое простое объяснение, которое вы когда-либо найдете.

В этой статье муж переписывает рассказ, где муж объясняет жене об ОТДЫХЕ, в чистом непрофессиональном плане. Должен прочитать!

how-i-explained-rest-to-my-wife (оригинальная ссылка)
how-i-explained-rest-to-my-wife (2013-07-19 рабочая ссылка)


Простое объяснение SOAP и REST

SOAP - «Простой протокол доступа к объектам»

SOAP - это способ передачи сообщений или небольших объемов информации через Интернет. Сообщения SOAP отформатированы в XML и обычно отправляются с использованием протокола HTTP (протокол передачи гипертекста).

Отдых - передача состояния представления

Отдых - это простой способ отправки и получения данных между клиентом и сервером, и у него не очень много определенных стандартов. Вы можете отправлять и получать данные как JSON, XML или даже обычный текст. Это легкий вес по сравнению с SOAP.


SOAP - простой протокол доступа к объектам - это протокол !

REST - REpresentational State Transfer - это архитектурный стиль !

SOAP - это XML-протокол, используемый для передачи сообщений, как правило, через HTTP

REST и SOAP , возможно, не являются взаимоисключающими. Архитектура RESTful может использовать HTTP или SOAP или какой-либо другой протокол связи. REST оптимизирован для Интернета, и, таким образом, HTTP является идеальным выбором. HTTP также является единственным протоколом, обсуждаемым в статье Роя Филдинга.

Хотя REST и SOAP явно отличаются друг от друга, вопрос освещает тот факт, что REST и HTTP часто используются в тандеме. Это в первую очередь связано с простотой HTTP и ее очень естественным отображением для принципов RESTful.

Основные принципы REST

Связь клиент-сервер

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

Stateless

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

Cacheable

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

Равномерный интерфейс

Все компоненты должны взаимодействовать через единый унифицированный интерфейс. Поскольку взаимодействие всех компонентов происходит через этот интерфейс, взаимодействие с различными службами очень простое. Интерфейс тот же! Это также означает, что изменения в реализации могут быть сделаны изолированно. Такие изменения не повлияют на взаимодействие фундаментальных компонентов, поскольку равномерный интерфейс всегда остается неизменным. Один из недостатков заключается в том, что вы застряли в интерфейсе. Если оптимизация может быть предоставлена ​​конкретной службе, изменив интерфейс, вам не повезло, поскольку REST запрещает это. Однако с яркой стороны REST оптимизирован для Интернета, поэтому невероятная популярность REST по HTTP!

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

См. Это сообщение в блоге о дизайнерах REST Design для получения более подробной информации о REST и указанных выше марках.


REST - это стиль архитектуры для проектирования сетевых приложений. Идея состоит в том, что вместо использования сложных механизмов, таких как CORBA, RPC или SOAP для соединения между машинами, простой HTTP используется для совершения вызовов между машинами.


SOAP-основанные веб-сервисы. Короче говоря, модель SOAP-based Services рассматривает мир как экосистему равных коллег, которые не могут контролировать друг друга, но должны работать вместе, соблюдая опубликованные контракты. Это действительная модель беспорядочного реального мира, а контракты на основе метаданных образуют интерфейс SOAP Service Interface.

мы все же можем связывать SOAP с удаленными вызовами процедур на основе XML, но технология SOAPbased Web Services превратилась в гибкую и мощную модель обмена сообщениями.

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

Контракты между системами коллективно называются метаданными и содержат описания сервисов, поддерживаемые шаблоны обмена сообщениями и политики, определяющие качества обслуживания (услуга может потребоваться зашифровать, надежно доставить и т. Д.). Описание услуги, в свою очередь, является подробным спецификация данных (документов сообщений), которые будут отправлены и получены системой. Документы описываются с использованием языка описания XML, такого как XML Schema Definition. Пока все системы соблюдают свои опубликованные контракты, они могут взаимодействовать, а изменения во внутренних системах никогда не влияют на другие. Каждая система отвечает за перевод собственных внутренних реализаций в свои контракты и из их контрактов

REST - передача репрезентативного состояния. Физическим протоколом является HTTP. В принципе, REST - это то, что все уникальные ресурсы в Интернете однозначно идентифицируются по URL-адресу. Все операции, которые могут выполняться на этих ресурсах, могут быть описаны ограниченным набором глаголов (глаголы «CRUD»), которые, в свою очередь, сопоставляются с HTTP-глаголами.

REST намного меньше «тяжеловеса», чем SOAP.

Работа с веб-сервисом


Канарейка в угольной шахте.

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

Предупреждающие знаки

Вы абсолютно правы, для создания клиентов RESTful требуется больше времени, чем клиенты SOAP. Инструментарий SOAP отнимает много кода шаблона и делает объекты клиентского прокси доступными практически без усилий. С помощью инструмента, такого как Visual Studio и URL-адреса сервера, я могу получить доступ к удаленным объектам произвольной сложности, локально менее чем за пять минут.

Службы, которые возвращают приложение / xml и application / json, так раздражают разработчиков-клиентов. Что мы должны делать с этим блоком данных?

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

SOAP накладные расходы, га. Это латентность, которая убивает. Если люди действительно обеспокоены количеством лишних байтов, проходящих через провод, то, возможно, HTTP не является правильным выбором. Вы видели, сколько байтов используется заголовком user-agent?

Да, вы когда-нибудь пробовали использовать веб-браузер в качестве инструмента отладки для чего-либо, кроме HTML и javascript. Поверьте мне, это отстой. Вы можете использовать только два глагола, кеширование постоянно мешает, обработка ошибок проглатывает так много информации, она постоянно ищет проклятый favicon.ico. Просто застрелите меня.

Читаемый URL. Только существительные, не глаголы. Да, это легко до тех пор, пока мы выполняем только операции CRUD, и нам нужно только получить доступ к иерархии объектов одним способом. К сожалению, для большинства приложений требуется немного больше функциональности.

Надвигающаяся катастрофа

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

Тем не менее, они находят, что управление версиями является такой же проблемой, но компилятор не помогает выявлять проблемы. Письменный клиентский код - это боль, которую нужно поддерживать, когда структуры данных развиваются, а URL-адреса получают рефакторинг. Проектирование API вокруг только существительных и четырех глаголов может быть очень тяжелым, особенно с реестрами RESTful Url, которые сообщают вам, когда вы можете и не можете использовать строки запроса.

Разработчики собираются начать спрашивать, почему мы тратим наши усилия на поддержку форматов Json и форматов Xml, почему бы не сосредоточить наши усилия на одном и сделать это хорошо?

Как все пошло не так

Я скажу вам, что пошло не так. Мы, как разработчики, позволили отделам маркетинга воспользоваться нашей основной слабостью. Наш вечный поиск серебряной пули ослепил нас реальностью того, что НАХОДИТ на самом деле. Поверхность REST кажется такой простой и простой. Назовите свои ресурсы URL-адресами и используйте GET, PUT, POST и DELETE. Черт, у нас разработчики уже знают, как это сделать, мы работаем с базами данных в течение многих лет, которые имеют таблицы и столбцы и операторы SQL, которые имеют SELECT, INSERT, UPDATE и DELETE. Это должен был быть кусок пирога.

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

Эта политая версия REST во многих отношениях подтвердилась в культуре разработчиков. Были созданы серверные рамки, которые поощряли идентификацию ресурсов и единый интерфейс, но не помогли другим ограничениям. Термины начали плавать вокруг дифференциации подходов (HI-REST против LO-REST, Corporate REST vs Academic REST, REST vs RESTful).

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

REST, этот термин определенно стал основным. Почти каждый основной веб-ресурс, имеющий API, поддерживает «REST». Twitter и Netflix - два очень высокого уровня. Страшно то, что я могу думать только об одном публичном API, который является самоописательным, и есть горстка, которая действительно реализует ограничение гипермедиа. Конечно, некоторые сайты, такие как и Gowalla, поддерживают ссылки в своих ответах, но в их ссылках есть огромные дыры. У API нет корневой страницы. Представьте, насколько успешным был бы веб-сайт, если бы не была домашняя страница для веб-сайта!

Вы были введены в заблуждение, я боюсь

Если вы сделали это так далеко, короткий ответ на ваш вопрос заключается в том, что API (Netflix и Twitter) не соответствуют всем ограничениям, и поэтому вы не получите преимуществ, которые должны принести REST apis.

Клиенты REST занимают больше времени, чем SOAP-клиенты, но не привязаны к одной конкретной службе, поэтому вы должны иметь возможность повторно использовать их через службы. Возьмем классический пример веб-браузера. Сколько услуг может получить доступ к веб-браузеру? Как насчет Feed Reader? Теперь, сколько различных сервисов может получить доступ к среднему клиенту Twitter? Да, только один.

Клиенты REST не должны создаваться для взаимодействия с одной службой, они должны быть созданы для обработки определенных типов носителей, которые могут обслуживаться любой службой. Очевидным вопросом является то, как вы можете создать клиент REST для службы, которая предоставляет приложение / json или application / xml. Ну, ты не можешь. Это связано с тем, что эти форматы совершенно бесполезны для клиента REST. Вы сами это сказали,

вы должны сделать «догадки» относительно того, что вернется через трубу, поскольку нет реальной схемы или справочного документа

Вы абсолютно правы для таких сервисов, как Twitter. Однако самоописательное ограничение в REST говорит о том, что заголовок типа HTTP-содержимого должен точно описывать содержимое, которое передается по проводу. Доставка приложения / json и application / xml ничего не сообщает о содержании.

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

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

Ваша последняя точка зрения на читаемые URL-адреса является самым ироничным. Если вы действительно выполняете ограничение гипермедиа, каждый URL-адрес может быть GUID, и клиентский разработчик ничего не потеряет в удобочитаемости.

Тот факт, что URI должны быть непрозрачными для клиента, является одним из самых важных при разработке систем REST. Читаемые URL-адреса удобны для разработчика сервера, а хорошо структурированные URL-адреса упрощают отправку запросов на серверную инфраструктуру, но это детали реализации, которые не должны влиять на разработчиков, потребляющих API.

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

Возможно, это не их вина

Я потратил много демпинга на поставщиков услуг, но требуется два танца RESTfully. Служба может соблюдать все ограничения религиозно, и клиент все еще может легко отменить все преимущества.

Если клиентские жесткие коды запрашивают доступ к определенным типам ресурсов, это мешает серверу изменять эти URL-адреса. Любая конструкция URL-адреса, основанная на неявном знании того, как служебная структура создает свои URL-адреса, является нарушением.

Предположение о том, какой тип представления будет возвращен из ссылки, может привести к проблемам. Сделав предположения о содержании представления на основе знаний, которые явно не указаны в заголовках HTTP, определенно создаст связь, которая в будущем вызовет боль.

Должны ли они использовать SOAP?

Лично я так не думаю. REST done right позволяет распределенной системе развиваться в долгосрочной перспективе. Если вы создаете распределенные системы, в которых есть компоненты, разработанные разными людьми и которые должны длиться много лет, то REST - довольно хороший вариант.





rest soap