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

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

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

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

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

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

Я хотел бы видеть такие ответы:

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

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

8 114
database-restore amazon-web-services soap architecture

8 ответов:

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

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

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

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

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

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

обновление

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

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

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

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

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

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

Это примеры отдыха архитектура за работой.

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

  • пресловутого проблема с кнопкой Назад вызвано использованием серверной стороны состояние сеанса.
  • балансировка нагрузки может стать боли при у вас есть состояние сеанса на стороне сервера.
  • Flash-приложений часто предотвратить URL from specifically identifying один представление.
  • другая проблема, которая ломает веб браузеры плохо соответствуют медиа-стандартов. Мы слышим все время о том, как IE6 должен быть убитый. Проблема в том, что стандарты не соблюдались должным образом, или были проигнорированы по какой-то причине.
  • использование сеансов входа в систему являются источник многих дыр в безопасности.

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

123

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

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

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

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

и это действительно подводит итог. Отдых во многом более элегантный.

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

10

с здесь:

остальные преимущества:

  • легкий - не так много дополнительной разметки xml
  • Читаемые Человеком Результаты
  • простота сборки - не требуется набор инструментов

также проверить этой выход:

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

8

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

просто чтобы вытащить тебя,

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

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

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

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

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

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

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

8

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

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

4

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

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

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

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

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

3

вот некоторые идеи:

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

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

3

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

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

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

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

2