Зачем нам нужны веб-сервисы RESTful?
Я собираюсь изучить веб-сервисы RESTful (лучше сказать, что мне придется это сделать, потому что это часть магистерской программы CS).
Я прочитал некоторую информацию в Википедии, и я также прочитал статью о REST в Sun Developer Network, и я вижу, что это непростая технология, есть специальные рамки для создания приложений RESTful, и его часто сравнивают с веб-службами SOAP, и программист должен понимать, когда использовать SOAP и когда отдых может быть приятным подход.
Я помню, что несколько лет назад мыло было очень популярным (модным?) и пункт "мыло" должен был присутствовать в каждом хорошем резюме. Но на практике он используется очень редко и для достижения очень простых целей.
Мне кажется, что отдых-это еще одно "последнее слово моды" (или я могу быть совершенно неправ, потому что я никогда не видел отдыха на практике).
можете ли вы дать мне несколько примеров, когда следует использовать отдых и почему мы не можем сделать то же самое без отдыха (или почему мы должны тратить гораздо больше времени, чтобы делать то же самое без отдыха)?
UPD: к сожалению, я не вижу никаких конкретных аргументов, которые могут взорвать мой разум в первых комментариях. Заставьте меня думать, что отдых-это потрясающая технология!
Я хотел бы видеть такие ответы:
Я разрабатывал еще один комплекс Приложение HelloWorld, и нам нужно передача большого количества / крошечных данных и I предложенное решение для отдыха моему напарнику:
– но мыло старомодные технологии из прошлого века и мы можем использовать лучше один.
8 ответов
REST следует использовать, если это очень важно для вас минимизировать соединение между клиентскими и серверными компонентами в распределенном приложении.
Это может быть так, если ваш сервер будет использоваться много разных клиентов что у вас нет контроля. Это также может быть так, если вы хотите иметь возможность регулярно обновляйте сервер без необходимости обновления клиентского программного обеспечения.
Я могу заверить вас что достижение этого низкого уровня сцепления не просто. Крайне важно следовать всем ограничениям отдыха, чтобы добиться успеха. Поддержание связи чисто без гражданства сложно. Выбор правильных типов носителей и сжатие ваших данных в форматы сложно. Создание собственных типов носителей может быть еще сложнее.
адаптация богатого поведения сервера в единый HTTP-интерфейс может быть запутанной и иногда кажется педантичной по сравнению с относительно простой подход RPC.
несмотря на трудности, преимущества заключаются в том, что у вас есть сервис, который разработчик клиента должен быть в состоянии легко понять из-за последовательного использования протокола HTTP. Услуга должна быть легко обнаруживается благодаря гипермедиа и клиент должен быть крайне устойчива к изменениям на сервере.
преимущества гипермедиа и избегание состояния сеанса делают балансировку нагрузки простой и возможно разделение служб. Строгое соответствие правилам HTTP делает доступность таких инструментов, как отладчики и кэширование прокси замечательной вещью.
обновление
Мне кажется, что отдых-это другое "последнее слово моды" (или я могу быть совершенно не прав, потому что я никогда ... видел отдых на практике).
Я думаю, что отдых стал модным, потому что люди, пытающиеся сделать проекты типа SOA, имеют обнаружено, что с помощью стека SOAP они не реализуют обещанные преимущества. Люди продолжают возвращаться к интернету в качестве примера простых методологий интеграции. К сожалению, я думаю, что люди недооценивают объем планирования и предвидения, которые пошли на создание интернета, и они упрощают то, что нужно сделать, чтобы позволить случайному повторному использованию, которое происходит в интернете.
вы говорите, что никогда не видели отдыха на практике, но это невозможно true, если вы когда-либо использовали веб-браузер. Веб-браузер является клиентом 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 от конкретно идентификации ля представление.
- другая проблема, которая ломает веб браузеры плохо соответствуют медиа-стандартов. Мы слышим все время о том, как IE6 должен быть убитый. Проблема в том, что стандарты не соблюдались должным образом, или были проигнорированы по какой-то причине.
- использование сеансов входа в систему источник многих дыр в безопасности.
отдых везде. Это часть сети, которая заставляет ее работать хорошо. Если вы хотите построить распределенные приложения, которые могут масштабироваться, как веб, быть устойчивыми к изменениям, как веб, и способствовать повторному использованию, как это сделал веб, а затем следовать тем же правилам, что и при создании веб-браузеров.
отдых был начат, насколько мне известно, диссертацией Роя Филдинга архитектурные стили и проектирование сетевых программных архитектур, который стоит прочитать, если вы еще не смотрели на него.
в верхней части диссертации есть цитата:
почти каждый чувствует себя в мире с природой: слушая океан волны на берегу, у спокойного озера, в травяном поле, на ветром пустоши. Однажды, когда мы узнали вечный путь то же самое мы будем чувствовать и по отношению к нашим городам. многое в них, как мы делаем сегодня, гуляя по берегу океана, или растянулся в высокой траве луга.
- Кристофер Александр, вневременной способ строительства (1979)
и это действительно подводит итог. Отдых во многом более элегантен.
SOAP-это протокол поверх HTTP, поэтому он обходит множество http-конвенций для создания новых соглашения в SOAP и в ряде случаев избыточны с HTTP. HTTP, однако, более чем достаточно для восстановления, поиска, записи и удаления информации через HTTP, и это многое из того, что REST. Поскольку REST построен с HTTP, а не поверх него, это также означает, что программное обеспечение, которое хочет интегрироваться с ним (например, веб-браузер), не должно понимать SOAP, чтобы сделать это, просто HTTP, который должен быть наиболее широко понят и интегрирован-с протоколом, используемым в этом точка.
с здесь:
остальные преимущества:
- легкий-не много дополнительной разметки xml
- Читаемые Человеком Результаты
- легко построить - не требуются наборы инструментов
также проверить этой out:
чтобы быть справедливым, REST не является лучшим решением для каждого веб-сервиса. Данные, которые должны быть безопасными, не должны отправляться в качестве параметров в URIs. И большой объемы данных, как в подробных заказах на покупку, могут быстро стать громоздкими или даже выходить за рамки URI. В этих случаях мыло действительно является твердым раствором. Но важно сначала попробовать отдохнуть и прибегать к мылу только при необходимости. Это помогает поддерживать простоту и доступность разработки приложений.
Я могу с уверенностью сказать, что я потратил много времени, чтобы понять это как Новичок, но это лучшая ссылка, чтобы начать с отдыха с нуля! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa
просто чтобы вытащить тебя,
подумайте о том, что такое" традиционный веб-сервис". Это интерфейс с разоблаченные " методы."Клиенты знают имя, вход и выход методов а значит, можно их называть.
теперь представьте себе интерфейс, который не предоставляет "методы". Вместо этого выставляет "объекты". Поэтому, когда клиент видит этот интерфейс, все, что он видит является одним или несколькими "объектами". "Объект" не имеет входа и выхода – потому что"она ничего не делает". Это существительное, а не глагол. Это " вещь", а не"действие".
например, подумайте о традиционной веб-службе, которая предоставляет текущие погодные условия, если вы предоставляете его с городом. Наверное имеет веб-метод, такой как GetWeatherInfo (), который принимает город в качестве входных данных и предоставляет данные о погоде в выходные. Это легко для вас до сих пор понять, как клиент будет использовать эту веб-службу.
теперь представьте, что на месте вышеуказанного веб-сервиса появился новый это выставляет города как объекты. Итак, когда вы смотрите на него как на клиента, вместо GetWeatherInfo () вы видите Нью-Йорк, Даллас, Лос-Анджелес, Лондон и так далее. И эти города не имеют никакого применения конкретные методы подвешивания от них-они как будто инертны газы - они сами не реагируют.
вы должны думать – ну, как это поможет вам, как клиенту, добраться до погоды Далласа? Мы доберемся до этого через несколько минут.
Если все, что вы получаете от веб-службы, это "набор объектов", очевидно, вы нужен способ "действовать по ним". Сами объекты не имеют методов для вас, чтобы позвонить, так что вам нужен набор действий, которые вы можете применить на подобные объекты. В другими словами, вам нужно "применить глагол к существительному". Если вы видите объект, скажем, яблоко, которое является "существительным", вы можете применить "глагол" как есть, к нему. Но не все глаголы могут быть применены ко всем существительные. Например, вы можете водить машину, но не можете водить телевизор.
таким образом, если веб-служба предоставляет только объекты – и вас спрашивают-Ну, давайте теперь разработаем несколько стандартных действий или глаголов, которые "все клиенты может применяться ко всем объектам, которые они видят",...
большинство ответов " pro " о REST, похоже, исходят от людей, которые никогда не разрабатывали веб-службу SOAP или клиент, используя среду, которая предоставляет соответствующие инструменты для задачи. Они жалуются на проблемы, с которыми я просто никогда не сталкивался, используя Visual Studio .NET и IBM Rational Web Developer. Я полагаю, что если вам нужно разработать веб-службы или клиенты на языке сценариев или на каком-либо другом языке с небольшой поддержкой инструментов или без нее, они действительны жалобы.
Я также должен признать, что некоторые из" про " точек звучат как вещи, которые на самом деле могут быть правдой, но я никогда не видел примера, который иллюстрирует их ценность. В частности, я был бы очень признателен, если бы кто-то опубликовал комментарий, содержащий ссылку на хороший пример веб-службы REST. Это должен быть тот, который использует несколько уровней ресурсов, возможно, в иерархии, и который использует типы носителей правильно. Может быть, если я посмотрю на хороший пример, я поймите, в таком случае, я вернусь сюда и признаю это.
чтобы добавить немного прозаический поворот к ответам, уже данным, причина, по которой мы используем службы REST, где я нахожусь, заключается в том, что если вы знаете, что можете передать бизнес-партнеру URL-адрес и знать, что они получат взамен красиво выложенную плиту XML независимо от того, работают ли они в .Net x.x, PHP, Python, Java, Ruby или бог знает что это сильно уменьшает головные боли.
Это также означает, что на нетехническом конце наши продавцы могут хвастаться нашим универсальным API людям без страха выглядите как полные куклы.
много не только технические преимущества все это просто не обидчивый объяснять, демонстрировать и чувствовать себя уверенно-это хорошо. Мыло, хотя так же круто для технарей, гораздо менее доступно для нетехников и, следовательно, не так легко "продать".
Я склонен замечать, что вещи, не-технари могут получить свою голову вокруг, как правило, прилипают. Поэтому я сомневаюсь, что отдых как техника может быть так же восприимчив, как мыло к прихотям мода.
но все эти вещи о том, чтобы не помещать ничего в службу REST, которая должна быть заблокирована, вдвойне верны, хотя бы потому, что технология так легко понимается людьми, которые не так технически мыслят.
вот некоторые идеи:
- REST ограничивает вашу службу для использования единого интерфейса. Вам не нужно тратить время на мечты (или споры) обо всех возможных способах работы вашего сервиса - вы получаете право работать, определяя ресурсы в вашей системе. Оказывается, это большая работа сама по себе, но, к счастью, проблемы, как правило, гораздо лучше определены.
- С ресурсами, их ассоциациями и их представлениями в руке, действительно очень мало что можно сделать в реализации вашего сервиса, потому что многие решения были приняты за вас.
- ваша система будет очень похожа на другие системы RESTful; кривые обучения для товарищей по команде, партнеров и клиентов будут сокращены.
- У вас будет общий словарь для обсуждения проблем дизайна с другими разработчиками и даже с теми, кто менее технически мыслит (например, клиенты).
- как говорит Даррел, потому что вы используете гипертекст-управляемый дизайн, ваш сервис сужает область соединения только до одной вещи - типов носителей. Это помогает вам как разработчику, потому что изменения в вашей системе содержатся в узкой полосе контакта. Это помогает вашим клиентам в том, что меньшее количество ваших изменений нарушит их код.
- почти каждая проблема, которая может возникнуть при реализации REST, может быть решена разоблачение нового ресурса или переосмысление вашей ресурсной модели. Этот фокус, ИМО, большая урожайность повышение.
итог, REST удаляет многие из самых трудоемких и спорных решений по дизайну и реализации из рабочего процесса вашей команды. Это отвлекает ваше внимание от реализация службу проектирование его. И он делает это без нагромождения gobbledygook на протокол HTTP.
REST-это стиль архитектуры для разработки сетевых приложений. Идея заключается в том, что вместо использования сложных механизмов, таких как CORBA, RPC или SOAP для соединения между машинами, простой HTTP используется для выполнения вызовов между машинами.
во многих отношениях сама Всемирная паутина, основанная на HTTP, может рассматриваться как архитектура на основе REST. Приложения RESTful используют HTTP-запросы для публикации данных (создания и/или обновления), чтения данных (например, создания запросов) и удаления данных. Таким образом, REST использует HTTP для всех четырех операций CRUD (Create/Read/Update/Delete).
REST-легкая альтернатива таким механизмам, как RPC (удаленные вызовы процедур) и веб-службы (SOAP, WSDL и др.). Позже мы увидим, насколько проще отдых.
несмотря на простоту, REST является полнофункциональным; в веб-службах нет ничего, что вы не можете сделать с архитектурой RESTful. Отдых не является "стандартом". Там никогда не будет W3C recommendataion для отдыха, для образец. И хотя существуют фреймворки программирования REST, работа с REST настолько проста, что вы часто можете "свернуть свой собственный" со стандартными функциями библиотеки на таких языках, как Perl, Java или C#.