Зачем нам RESTful Web Services?

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

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

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

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

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

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

Я хотел бы видеть ответы вроде этого:

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

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

Ответ 1

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

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

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

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

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

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

Обновление

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

В верхней части диссертации приведена цитата:

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

- Кристофер Александр, "Вечный строй" (1979)

И это действительно подводит итог. REST во многом более изящный.

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

Ответ 3

От здесь:

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

Легкий - не много дополнительной разметки xml

Результаты, доступные для чтения.

Простота сборки - не требуется никаких инструментов.

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

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

Ответ 4

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

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

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

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

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

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

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

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

Таким образом, если веб-сервис expos "

Ответ 5

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

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