Я собираюсь изучить веб-сервисы 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 стал модным, потому что люди, пытающиеся реализовать проекты типа SOA, обнаружили, что, используя стек SOAP, они не осознают обещанных преимуществ. Люди продолжают возвращаться к Интернету как к примеру простых методологий интеграции. К сожалению, я думаю, что люди недооценивают объем планирования и предвидения, которые потребовались для создания сети, и слишком упрощают то, что необходимо сделать, чтобы позволить случайное повторное использование, которое действительно происходит в сети.
Вы говорите, что никогда не видели REST на практике, но это не может быть правдой, если вы когда-либо использовали веб-браузер. Веб-браузер - это клиент REST.
Это могут показаться глупыми вопросами, но если вы знаете ответ, то можете начать понимать, что такое REST. Посмотрите на StackOverflow, чтобы узнать больше о преимуществах REST. Когда я просматриваю вопрос, я могу добавить эту страницу в закладки или отправить ссылку другу, и он увидит ту же информацию. Ему не нужно перемещаться по сайту, чтобы найти этот вопрос.
StackOverflow использует различные службы OpenId для аутентификации, gravatar.com для изображений аватаров, google-analytics и Quantserve для аналитической информации. Такой вид интеграции нескольких компаний - это то, о чем мир SOAP только мечтает . Одним из лучших примеров является тот факт, что библиотеки jQuery, которые используются для управления пользовательским интерфейсом StackOverflow, извлекаются из сети доставки контента Google. Тот факт, что SO может направить клиента (например, ваш веб-браузер) на загрузку кода со стороннего сайта для повышения производительности, свидетельствует о слабой связи между веб-клиентом и сервером.
Это примеры работы архитектуры REST.
Теперь некоторые веб-сайты / приложения нарушают правила REST, и тогда браузер не работает должным образом.
ОТДЫХ везде. Это часть сети, которая заставляет его работать хорошо. Если вы хотите создавать распределенные приложения, которые могут масштабироваться, как Интернет, быть устойчивыми к изменениям, как Интернет, и способствовать повторному использованию, как это сделал Интернет, то следуйте тем же правилам, что и при создании веб-браузеров.
источник
Насколько мне известно, начало REST было положено диссертацией Роя Филдинга « Архитектурные стили и проектирование сетевых архитектур программного обеспечения» , которую стоит прочитать, если вы еще не смотрели на нее.
Вверху диссертации цитата:
Почти каждый чувствует себя в мире с природой: слушая океанские волны на берегу, у тихого озера, в поле травы, на ветреной пустоши. Однажды, когда мы снова узнаем вневременной путь, мы будем чувствовать то же самое в наших городах, и мы будем чувствовать себя в них так же спокойно, как сегодня, гуляя по океану или растянувшись в высокой траве луг.
- Кристофер Александр, вневременной способ строительства (1979)
И это действительно подводит итог. REST во многих отношениях более элегантен.
SOAP - это протокол поверх HTTP, поэтому он обходит множество соглашений HTTP для создания новых соглашений в SOAP и во многих отношениях является избыточным с HTTP. Однако HTTP более чем достаточно для получения, поиска, записи и удаления информации через HTTP, и это многое из того, что такое REST. Поскольку REST построен с использованием HTTP, а не поверх него, это также означает, что программное обеспечение, которое хочет интегрироваться с ним (например, веб-браузер), не должно понимать SOAP, чтобы сделать это, просто HTTP, который должен быть самым широко понятный и интегрированный с используемым на данный момент протоколом.
источник
От сюда :
Преимущества REST:
Также проверьте это :
источник
Я могу с уверенностью сказать, что я потратил много времени, чтобы понять это как новичок, но это лучшая ссылка, чтобы начать работу с REST с нуля! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa
Просто чтобы втянуть тебя,
источник
Вот несколько идей:
В итоге REST удаляет многие из наиболее трудоемких и спорных решений по проектированию и внедрению из рабочего процесса вашей команды. Это переключает ваше внимание с реализации вашего сервиса на его разработку . И это делается без наложения чепухи на протокол HTTP.
источник
MakeOrder
URL дляConfirmOrder
иCancelOrder
? Клиент еще не знает, как позвонить в службу, но ему нужны данные?Большинство «профессиональных» ответов о 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 #.
источник