Зачем нам нужны веб-сервисы RESTful?
6 ответов
REST следует использовать, если для вас очень важно минимизировать связь между клиентскими и серверными компонентами в распределенном приложении.
Это может иметь место, если ваш сервер будет использоваться от множества разных клиентов , над которыми вы не можете контролировать. Это также может иметь место, если вы хотите иметь возможность регулярно обновлять сервер без необходимости обновлять клиентское программное обеспечение.
Я могу заверить вас, что достижение такого низкого уровня связи не легко сделать . Для успеха крайне важно соблюдать все ограничения REST. Поддерживать соединение без гражданства сложно. Выбрать правильные типы мультимедиа и сжать данные в форматах непросто. Создание собственных типов мультимедиа может быть еще сложнее.
Адаптация разнообразного поведения сервера к единому HTTP-интерфейсу может сбивать с толку и иногда кажется педантичной по сравнению с относительно простым подходом RPC.
Несмотря на трудности, преимущества заключаются в том, что у вас есть услуга, которой должен быть разработчик клиента. легко понять благодаря последовательному использованию протокола HTTP. Служба должна быть легко обнаруживаемой благодаря гипермедиа , а клиент должен быть чрезвычайно устойчивым к изменениям на сервере .
Преимущества гипермедиа и предотвращение состояния сеанса делают балансировку нагрузки простое и разделение услуг возможно . Строгое соответствие правилам HTTP делает доступность таких инструментов, как отладчики и прокси-серверы кэширования замечательной вещью.
Обновление
Мне кажется, что REST - это другое
Несмотря на трудности, преимущества заключаются в том, что у вас есть сервис, который разработчик клиента должен быть в состоянии легко понять благодаря последовательному использованию протокола HTTP. Служба должна быть легко обнаруживаемой благодаря гипермедиа , а клиент должен быть чрезвычайно устойчивым к изменениям на сервере .
Преимущества гипермедиа и избежание состояния сеанса делают балансировку нагрузки простое и разделение услуг возможно . Строгое соответствие правилам HTTP делает доступность таких инструментов, как отладчики и прокси-серверы кэширования замечательной вещью.
Обновление
Мне кажется, что REST - это другое
Несмотря на трудности, преимущества заключаются в том, что у вас есть сервис, который разработчик клиента должен быть в состоянии легко понять благодаря последовательному использованию протокола HTTP. Служба должна быть легко обнаруживаемой благодаря гипермедиа , а клиент должен быть чрезвычайно устойчивым к изменениям на сервере .
Преимущества гипермедиа и предотвращение состояния сеанса делают балансировку нагрузки простое и разделение услуг возможно . Строгое соответствие правилам HTTP делает доступность таких инструментов, как отладчики и прокси-серверы кэширования замечательной вещью.
Обновление
Мне кажется, что REST - это другое Служба должна быть легко обнаруживаемой благодаря гипермедиа , а клиент должен быть чрезвычайно устойчивым к изменениям на сервере .
Преимущества гипермедиа и предотвращение состояния сеанса делают балансировку нагрузки простое и разделение услуг возможно . Строгое соответствие правилам HTTP делает доступность таких инструментов, как отладчики и прокси-серверы кэширования замечательной вещью.
Обновление
Мне кажется, что REST - это другое Служба должна быть легко обнаруживаемой благодаря гипермедиа , а клиент должен быть чрезвычайно устойчивым к изменениям на сервере .
Преимущества гипермедиа и избежание состояния сеанса делают балансировку нагрузки простое и разделение услуг возможно . Строгое соответствие правилам HTTP делает доступность таких инструментов, как отладчики и прокси-серверы кэширования замечательной вещью.
Обновление
Мне кажется, что REST - это другое Строгое соответствие правилам HTTP делает доступность таких инструментов, как отладчики и прокси-серверы кэширования замечательной вещью.
Обновление
Мне кажется, что REST - это другое Строгое соответствие правилам 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 повсюду. Это та часть сети, которая заставляет его работать хорошо. Если вы хотите создавать распределенные приложения, которые могут масштабироваться, как Интернет, быть устойчивыми к изменениям, как Интернет, и способствовать повторному использованию, как это сделал Интернет, то следуйте тем же правилам, что и при создании веб-браузеров.
REST был начат, насколько мне известно, диссертацией Роя Филдинга Архитектурные стили и проектирование сетевых архитектур программного обеспечения , которую стоит прочитать, если вы еще не сделали этого. Я смотрел на это.
В верхней части диссертации есть цитата:
Почти каждый чувствует себя в мире с природой: слушая океан волны на берегу, у тихого озера, в траве, на ветреная пустошь. Однажды, когда мы узнали вневременной путь опять же, мы будем чувствовать то же самое к нашим городам, и мы будем чувствовать себя как в них мирно, как мы сегодня, гуляя по океану, или раскинувшийся в высокой траве на лугу.
- Кристофер Александр, Вневременный способ строительства (1979)
И это действительно подводит итог. REST во многих отношениях более элегантен.
SOAP - это протокол поверх HTTP, поэтому он обходит множество соглашений HTTP для создания новых соглашений в SOAP и во многих отношениях является избыточным с HTTP. Однако HTTP более чем достаточно для получения, поиска, записи и удаления информации через HTTP, а это многое из того, что такое REST. Поскольку REST построен с использованием HTTP, а не поверх него, это также означает, что программное обеспечение, которое хочет интегрироваться с ним (например, веб-браузер), не должно понимать SOAP, чтобы сделать это, просто HTTP, который должен быть самым широко понятный и интегрированный с используемым на данный момент протоколом.
Из здесь :
Преимущества REST:
- Легковесность - не много дополнительной разметки xml
- Результаты, удобочитаемые человеком
- Простота сборки - никаких инструментов не требуется
Также проверьте это out:
Честно говоря, REST - не лучшее решение для каждой Web-службы. Данные, которые должны быть защищены, не следует отправлять в качестве параметров в URI. А большие объемы данных, например, в подробных заказах на покупку, могут быстро стать громоздкими или даже выходить за рамки URI. В этих случаях SOAP действительно является надежным решением. Но важно сначала попробовать REST и прибегать к SOAP только при необходимости. Это помогает сделать разработку приложений простой и доступной.
Вот несколько идей:
- REST ограничивает вашу службу использованием унифицированного интерфейса. Вам не нужно тратить время на мечты (или споры) обо всех возможных способах работы вашего сервиса - вы получаете право работать, определяя ресурсы в вашей системе. Оказывается, сама по себе большая работа, но, к счастью, проблемы, как правило, определяются гораздо лучше.
- Имея в руках ресурсы, их ассоциации и их представления, действительно очень мало что можно сделать для реализации вашего сервиса, потому что множество решений были созданы для вас.
- Ваша система будет очень похожа на другие системы RESTful; кривые обучения для товарищей по команде, партнеров и клиентов будут сокращены.
- У вас будет общий словарный запас, чтобы обсуждать проблемы дизайна с другими разработчиками, и даже с теми, кто менее технически подкован (например, с клиентами).
- Как говорит Даррел, поскольку вы используете дизайн, управляемый гипертекстом , ваш сервис сужает область связи до одного - медиа типы. Это поможет вам как разработчику, поскольку изменения в вашей системе находятся в узком кругу контактов. Это поможет вашим клиентам в том, что меньшее количество ваших изменений приведет к поломке их кода.
- Почти все проблемы, которые могут возникнуть при реализации REST, могут быть решены путем открытия нового ресурса или переосмысления вашей модели ресурсов. Этот фокус, IMO, является большим увеличением производительности.
В итоге, REST удаляет многие из наиболее трудоемких и спорных решений по проектированию и внедрению из рабочего процесса вашей команды. Это переключает ваше внимание с реализации вашей службы на ее проектирование . И это происходит без нагромождения чепухи на протокол HTTP.
Чтобы добавить немного прозаического изложения к уже имеющимся ответам, учитывая причину, по которой мы используем службы REST, где я нахожусь, заключается в том, что если вы знаете, что можете передать бизнес-партнеру URL-адрес и знать, что он получит, взамен, красиво оформленный кусок XML, независимо от того, работают ли они в .Net xx, PHP, Python, Java, Ruby или бог знает что, это серьезно снижает головную боль.
Это также означает, что на не -технологическая сторона: наши продавцы могут хвастаться нашим универсальным API перед людьми, не опасаясь выглядеть как полноценные куклы.
Помимо технических преимуществ, все, что нетехническому специалисту легко объяснить, продемонстрировать и почувствовать себя уверенно, является хорошим вещь. Хотя протокол SOAP столь же хорош для технарей, он гораздо менее доступен для нетехнических специалистов, и поэтому его не так просто «продать».
Я часто замечаю, что вещи, которые не разбираются в технологиях, могут повредить своей голове, как правило, прилипают. Поэтому я сомневаюсь, что REST как метод может быть столь же восприимчив, как SOAP, к капризам моды.
Но все, что касается того, чтобы не помещать что-либо в службу REST, которая должна быть заблокирована, вдвойне верно, хотя бы потому, что технология такова. легко понимается людьми, не слишком технически развитыми.
Большинство «профессиональных» ответов о REST, похоже, исходят от людей, которые никогда не разрабатывали веб-службу или клиент SOAP, используя среду, которая предоставляет соответствующие инструменты для решения этой задачи. Они жалуются на проблемы, с которыми я просто никогда не сталкивался, используя Visual Studio .NET и IBM Rational Web Developer. Я полагаю, что если вам нужно разрабатывать веб-службы или клиентов на языке сценариев или на каком-то другом языке с небольшой поддержкой инструментов или без нее, то это обоснованные жалобы.
Я также должен признать, что некоторые из «за» моментов звучат как вещи, которые на самом деле могут быть правдой, но я никогда не видел примера, иллюстрирующего их ценность. В частности, я был бы очень признателен, если бы кто-нибудь разместил комментарий, содержащий ссылку на хороший пример веб-службы REST. Это должен быть тот, который использует несколько уровней ресурсов, возможно, в иерархии, и правильно использует типы мультимедиа. Может быть, если я посмотрю на хороший пример, я пойму, и в этом случае я вернусь сюда и признаю это.