Зачем нам нужны веб-службы RESTful?

123

Я собираюсь изучить веб-сервисы RESTful (лучше сказать, что мне придется это сделать, потому что это часть программы магистратуры CS).

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

Я помню, что несколько лет назад SOAP был очень популярен (модным?), И пункт «SOAP» должен был присутствовать в каждом хорошем резюме. Но на практике он использовался очень редко и для достижения очень простых целей.

Мне кажется, что REST - это еще одно «последнее слово моды» (или я могу ошибаться, потому что никогда не видел REST на практике).

Можете ли вы привести мне несколько примеров, когда следует использовать REST и почему мы не можем сделать то же самое без REST (или почему мы должны тратить гораздо больше времени на то же самое без REST)?

UPD : К сожалению, в первых комментариях я не вижу конкретных аргументов, которые могут взорвать мою голову. Заставьте меня думать, что REST - потрясающая технология!

Хотелось бы видеть такие ответы:

Я разрабатывал еще одно сложное приложение HelloWorld, и нам нужно передать много / крошечных данных, и я предложил своему коллеге решение REST:

- Вот черт! Джонни, мы обязательно должны использовать REST для реализации этого приложения!
- Да, Билли, мы можем использовать REST, но лучше использовать SOAP. Поверьте, я кое-что знаю о разработке приложений HelloWorld.
- Но SOAP - это устаревшая технология прошлого века, и мы можем использовать ее лучше.
- Билли, ты готов потратить 3 дня на эксперименты с REST? Мы можем сделать это с помощью SOAP за 2 часа ..
- Да, я уверен, что мы потратим еще больше времени на достижение той же безопасности / производительности / / масштабируемости / чего угодно еще с SOAP. Я уверен, что приложения HelloWorld теперь должны разрабатываться только на REST.

Роман
источник
2
Это не крутая технология - это другая технология. Если вы хотите, чтобы кто-то убедил вас, что это круто и нужно использовать каждый раз, обратитесь к консультанту.
quillbreaker

Ответы:

133

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

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

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

Адаптация разнообразного поведения сервера к единому HTTP-интерфейсу может сбивать с толку и иногда кажется педантичной по сравнению с относительно простым подходом RPC.

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

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

Обновить

Мне кажется, что REST - это еще одно «последнее слово моды» (или я могу ошибаться, потому что никогда не видел REST на практике).

Я думаю, что REST стал модным, потому что люди, пытающиеся реализовать проекты типа SOA, обнаружили, что, используя стек SOAP, они не осознают обещанных преимуществ. Люди продолжают возвращаться к Интернету как к примеру простых методологий интеграции. К сожалению, я думаю, что люди недооценивают объем планирования и предвидения, которые потребовались для создания сети, и слишком упрощают то, что необходимо сделать, чтобы позволить случайное повторное использование, которое действительно происходит в сети.

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

  • Почему вам не нужно обновлять браузер, когда кто-то меняет какой-то html на веб-сайте?
  • Почему я могу добавить полный новый набор страниц на веб-сайт, а «клиент» все еще может получить доступ к этим новым страницам без обновления?
  • Почему мне не нужно предоставлять "язык-описания-службы" веб-браузеру, чтобы сообщать ему, когда он переходит на http://example.org/images/cat, что возвращаемым типом будет изображение jpeg, а когда вы перейдете для http://example.org/description/cat возвращаемый тип будет text / html?
  • Почему я могу использовать веб-браузер для посещения сайтов, которые не существовали на момент выпуска браузера? Как клиент может узнать об этих сайтах?

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

StackOverflow использует различные службы OpenId для аутентификации, gravatar.com для изображений аватаров, google-analytics и Quantserve для аналитической информации. Такой вид интеграции нескольких компаний - это то, о чем мир SOAP только мечтает . Одним из лучших примеров является тот факт, что библиотеки jQuery, которые используются для управления пользовательским интерфейсом StackOverflow, извлекаются из сети доставки контента Google. Тот факт, что SO может направить клиента (например, ваш веб-браузер) на загрузку кода со стороннего сайта для повышения производительности, свидетельствует о слабой связи между веб-клиентом и сервером.

Это примеры работы архитектуры REST.

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

  • Печально известная проблема с кнопкой «Назад» вызвана использованием состояния сеанса на стороне сервера.
  • Балансировка нагрузки может стать проблемой, когда у вас есть состояние сеанса на стороне сервера.
  • Flash-приложения часто не позволяют URL-адресу конкретно идентифицировать представление.
  • Другая проблема, которая ломает веб-браузеры, - это плохое соответствие стандартам мультимедийного типа. Мы все время слышим о том, как нужно убить IE6. Проблема в том, что стандарты не соблюдались должным образом или игнорировались по какой-либо причине.
  • Использование сеансов входа в систему является источником многих дыр в безопасности.

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

Даррел Миллер
источник
@Darrell: как REST снижает связь по протоколу SOAP? Или как SOAP увеличивает связь по сравнению с REST? Вы имеете в виду тот факт, что клиенту SOAP действительно необходимо понимать протокол SOAP, а клиенту REST нужно понимать только типы носителей?
Джон Сондерс
4
@John Обычно способ использования SOAP заставляет клиента требовать «скомпилированных» знаний о каждой конечной точке на стороне сервера, каждом типе данных параметра и каждом возвращаемом типе. В мире SOAP нет рекомендаций по использованию стандартизованных типов для передачи данных между клиентом и сервером. Это означает, что каждая новая услуга, которую использует разработчик клиента, имеет свой собственный уникальный набор типов, конечных точек и протокола взаимодействия. Это сцепление.
Даррел Миллер
@John REST пытается стандартизировать протокол взаимодействия в соответствии с семантикой глаголов HTTP, форматы данных - в соответствии с зарегистрированными типами IANA, и все конечные точки должны быть динамически обнаруживаемыми. Это означает, что связь клиент / сервер ограничена определением типа носителя. Как сказал Рич, «ваш сервис сужает область связывания до одного - типов носителей».
Даррел Миллер
@ Даррелл: это не сцепление в традиционном смысле. Можно считать, что клиент "привязан" к метаданным (WSDL), но не к службе. Рассмотрим службу, которая возвращает «Сотрудника»: {int id; строка firstName, lastName, streetAddress1, streetAddress2, city, state; int zip;}. Кажется, вы предлагаете либо зарегистрировать «Сотрудника» в IANA, либо просто рассматривать «Сотрудник» как ассоциативный массив пар имя / значение.
Джон Сондерс,
@John Позвольте мне определить, что я имею в виду, говоря о соединении в терминах WSDL. Представьте, что у вас есть контракт на обслуживание, в который вы можете добавлять методы, удалять методы и переименовывать методы без перекомпиляции клиента. Учтите также, что клиент может быть направлен на использование этих новых методов без перекомпиляции. Контракт сообщения фиксируется HTTP, но может быть расширен с помощью заголовков, и контракт данных - единственное изменение, которое может сломать клиента, однако, используя метаданные в контракте сообщения, сервер может динамически доставлять клиенту соответствующую версию контракта данных.
Даррел Миллер,
11

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

Вверху диссертации цитата:

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

- Кристофер Александр, вневременной способ строительства (1979)

И это действительно подводит итог. REST во многих отношениях более элегантен.

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

quillbreaker
источник
Протокол SOAP был определен еще в 1998 году. Сколько «соглашений» HTTP было тогда соглашениями?
Джон Сондерс
Согласно этому w3.org/Protocols/HTTP/1.0/spec.html HTTP используется с 1990 года. И что? Все мы знаем, что единственная причина, по которой SOAP использует http, заключалась в том, что порт 80, скорее всего, был открыт на брандмауэре. Microsoft не собиралась снова повторять ошибку DCOM.
Даррел Миллер
1
« REST построен с использованием HTTP, а не поверх него » +1. Весь этот поток очень полезен для меня, чтобы понять обоснованность использования REST поверх SOAP и наоборот.
Chris22
9

От сюда :

Преимущества REST:

  • Легкий - не много лишней разметки xml
  • Человекочитаемые результаты
  • Простота сборки - не требуется никаких инструментов

Также проверьте это :

Честно говоря, REST - не лучшее решение для каждой веб-службы. Данные, которые должны быть защищены, не следует отправлять в качестве параметров в URI. А большие объемы данных, например, в подробных заказах на покупку, могут быстро стать громоздкими или даже выйти за рамки URI. В этих случаях SOAP действительно является надежным решением. Но важно сначала попробовать REST и прибегать к SOAP только при необходимости. Это помогает сделать разработку приложений простой и доступной.


источник
4
Комментарий о минусах не очень правильный. При перемещении параметра из URI в тело это по-прежнему небезопасно. Используйте SSL для безопасности. Кроме того, если данные в uri могут быть очень длинными, вам разрешается использовать post и помещать его в тело. Большинство серверных языков объединяют данные из параметров URI и параметров POST, поэтому никаких изменений на сервере не требуется.
Эмиль Иванов
1
@Emil - Имейте в виду, что SSL не всегда доступен. Некоторым людям нужна безопасность на основе сообщений, а не на транспортном уровне. А что касается использования тела POST ... POST - это один из глаголов, используемых для обработки запросов REST. Вы не всегда можете повторно использовать его для своих нужд.
Джастин Нисснер, 02
1
Большой минус: нет стандартизованного языка "описания", такого как WSDL для служб SOAP - каждая служба REST может быть или не может быть задокументирована, а качество документации сильно отличается от предлагаемой службы к другой .....
marc_s
3
@Marc_s Если REST выполнен правильно, нет необходимости в «языке описания», таком как WSDL. Используемые медиа-типы действительно должны быть задокументированы, но не должно существовать документации, которая связывает конечные точки с медиа-типами.
Даррел Миллер,
@Darrel: Мне очень жаль, но я не куплюсь на чушь "без языка описания". Даже если типы документов задокументированы, их также необходимо описать. Кроме того, некоторым людям нравится десериализовать контент в объекты на языке программирования. В этом случае очень полезно иметь машиночитаемое определение того, что служба может отправлять и получать, чтобы ваш инструмент мог создавать соответствующие классы и код сериализации.
Джон Сондерс
8

Я могу с уверенностью сказать, что я потратил много времени, чтобы понять это как новичок, но это лучшая ссылка, чтобы начать работу с REST с нуля! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

Просто чтобы втянуть тебя,

Подумайте о том, что такое «традиционный веб-сервис». Это интерфейс с открытыми «методами». Клиенты знают имя, ввод и вывод методов и, следовательно, могут их вызывать.

Теперь представьте интерфейс, который не предоставляет «методы». Вместо этого он обнажает «объекты». Поэтому, когда клиент видит этот интерфейс, он видит только один или несколько «объектов». «Объект» не имеет ввода и вывода - потому что «ничего не делает». Это существительное, а не глагол. Это «вещь», а не «действие».

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

А теперь представьте, что на месте вышеуказанного веб-сервиса есть новый, который представляет города как объекты. Итак, когда вы смотрите на него как на клиента, вместо GetWeatherInfo () вы видите Нью-Йорк, Даллас, Лос-Анджелес, Лондон и так далее. И у этих городов нет каких-то специфических методов, висящих на них - они, видимо, как инертные газы - сами не реагируют.

Вы, должно быть, думаете - а как это поможет вам, как клиенту, понять погоду Далласа? Мы вернемся к этому через несколько минут.

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

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

Раджараджан Пудупатти Сундари Дж.
источник
Так в чем же преимущество использования объекта вместо метода?
Soumya Rauth 03
4

Вот несколько идей:

  • REST ограничивает вашу службу использованием унифицированного интерфейса. Вам не нужно тратить время на мечтания (или споры) обо всех возможных способах работы вашего сервиса - вы получаете право работать, определяя ресурсы в вашей системе. Оказывается, сама по себе большая работа, но, к счастью, проблемы, как правило, определяются гораздо лучше.
  • Имея в руках ресурсы, их ассоциации и их представления, мало что можно сделать для реализации вашего сервиса, потому что многие решения были приняты за вас.
  • Ваша система будет очень похожа на другие системы RESTful; кривые обучения для товарищей по команде, партнеров и клиентов будут сокращены.
  • У вас будет общий словарный запас, чтобы обсуждать проблемы дизайна с другими разработчиками, и даже с менее технически подкованными (например, с клиентами).
  • Как говорит Даррел, поскольку вы используете дизайн, управляемый гипертекстом , ваш сервис сужает область связи до одного - типов мультимедиа. Это поможет вам как разработчику, поскольку изменения в вашей системе находятся в узком кругу контактов. Это помогает вашим клиентам в том, что меньшее количество ваших изменений нарушит их код.
  • Почти все проблемы, которые могут возникнуть при реализации REST, можно решить, открыв новый ресурс или переосмыслив модель ресурсов. Этот фокус, ИМО, - большой рост производительности.

В итоге REST удаляет многие из наиболее трудоемких и спорных решений по проектированию и внедрению из рабочего процесса вашей команды. Это переключает ваше внимание с реализации вашего сервиса на его разработку . И это делается без наложения чепухи на протокол HTTP.

Рич Аподака
источник
@John Если я запускаю VS и создаю проект WCF и создаю интерфейс с атрибутом [ServiceContract], я могу добавить любые вызовы методов, которые мне нравятся. CreateCustomer (), MakeOrder (), ConfirmOrder (), VerifyOrder (), SubmitOrder (), CheckStockAvailability (), CancelOrder () С помощью этих методов вы можете сказать мне, какую последовательность я должен использовать для обработки заказа? Можете ли вы сказать мне, когда мне будет разрешено вызывать CancelOrder ()? Стоит ли проверять наличие перед подтверждением заказа? Должен ли я проверять заказ перед проверкой наличия? Этот интерфейс вряд ли будет совместим с интерфейсом для расчета заработной платы.
Даррел Миллер
1
@Darrel: Я не понимаю, как REST помогает решить эту проблему. Выдает ли MakeOrderURL для ConfirmOrderи CancelOrder? Клиент еще не знает, как позвонить в службу, но ему нужны данные?
Джон Сондерс,
1
@John Совершенно верно. Клиент знает, что ему могут быть предоставлены URL-адреса ConfirmOrder и CancelOrder, но он не знает, как выглядят эти URL-адреса, и будет следовать за ними, только если они предоставлены. Вы называете это управляемым данными, Рой называет это Hypermedia как механизм состояния приложения.
Даррел Миллер
@Darrel: Думаю, я просто никогда не видел ни одной критически важной для бизнеса службы, где я хотел бы определить, что делать дальше, основываясь на том, какой URL-адрес был передан мне из предыдущего вызова.
Джон Сондерс
1
@JohnSaunders: это потому, что вызов REST связан не с вызовами методов, а с переходом состояния (подумайте о конечном автомате). В любом заданном состоянии сервер RESTful будет указывать допустимые переходы между состояниями, и пользователь или пользовательский агент выбирает переходы, которым он хочет следовать.
Ли Райан
4

Большинство «профессиональных» ответов о REST, похоже, исходят от людей, которые никогда не разрабатывали веб-службу или клиент SOAP, используя среду, которая предоставляет соответствующие инструменты для этой задачи. Они жалуются на проблемы, с которыми я просто никогда не сталкивался, используя Visual Studio .NET и IBM Rational Web Developer. Я полагаю, что если вам нужно разрабатывать веб-службы или клиентов на языке сценариев или на каком-либо другом языке с небольшой поддержкой инструментов или без нее, то это обоснованные жалобы.

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

Джон Сондерс
источник
На сегодняшний день лучшим публично доступным примером является Sun Cloud API. Вот пошаговое руководство kenai.com/projects/suncloudapis/pages/… Просто чтобы уточнить мой опыт работы с SOAP. Я создал и до сих пор поддерживаю веб-службы ASMX, используя Microsoft Web Service Software Factory из группы Patterns and Practices. Я создал службы на основе WCF, используя более позднюю версию той же фабрики программного обеспечения. Я также использовал WCF System.ServiceModel.Web, поскольку он был впервые выпущен вместе с Biztalk Services SDK в мае 2007 года.
Даррел Миллер,
1
Джон: один из примеров API для отдыха - Amazon. У них есть как @SOAP, так и REST API. Это может быть полезно для вас - docs.amazonwebservices.com/AmazonS3/latest/…
RichardOD
3

Чтобы добавить немного прозаику к ответам, уже учитывая причину, по которой мы используем службы REST, где я нахожусь, заключается в том, что если вы знаете, что можете передать бизнес-партнеру URL-адрес, и знаете, что они получат взамен красиво оформленный кусок XML независимо от того, работают ли они в .Net xx, PHP, Python, Java, Ruby или бог весть, что это сильно снижает головную боль.

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

Помимо технических преимуществ, все, что нетехническому специалисту легко объяснить, продемонстрировать и почувствовать себя уверенно, - это хорошо. Хотя протокол SOAP столь же хорош для технарей, он гораздо менее доступен для нетехнических специалистов, и поэтому его не так просто «продать».

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

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


источник
3

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

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

REST - это легкая альтернатива таким механизмам, как RPC (удаленные вызовы процедур) и веб-службы (SOAP, WSDL и др.). Позже мы увидим, насколько REST проще.

Несмотря на простоту, REST является полнофункциональным; в веб-службах практически нет ничего такого, чего нельзя было бы сделать с помощью архитектуры RESTful. REST не является «стандартом». Например, никогда не будет рекомендаций W3C для REST. И хотя существуют фреймворки программирования REST, работать с REST настолько просто, что вы часто можете «использовать свои собственные» функции стандартной библиотеки на таких языках, как Perl, Java или C #.

Картик Кумар
источник
« Во многих отношениях саму всемирную паутину, основанную на HTTP, можно рассматривать как архитектуру на основе REST. Приложения RESTful используют HTTP-запросы для публикации данных (создания и / или обновления), чтения данных (например, выполнения запросов), и удалить данные. Таким образом, REST использует HTTP для всех четырех операций CRUD (Create / Read / Update / Delete) ». Это еще один отличный практический пример, который я могу вынести из этой статьи. Спасибо.
Chris 22