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

Я собираюсь изучить веб-сервисы 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.

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. Проблема в том, что стандарты не соблюдались должным образом или игнорировались по какой-либо причине.
• Использование сеансов входа в систему является источником многих дыр в безопасности.

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

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

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

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

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

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

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

От сюда :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 #.