web-services русском - Зачем нам RESTful Web Services?




apis pdf (8)

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


Answers

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

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


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

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

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

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

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

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

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

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

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


here :

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

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

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

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


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

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

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


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

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

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

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


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

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

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

- Кристофер Александр, «Бессрочный путь строительства» (1979)

И это действительно подводит итог. REST во многом более изящный.

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


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. Посмотрите на для получения дополнительных преимуществ REST. Когда я смотрю на вопрос, я могу пометить эту страницу или отправить URL-адрес другу, и он может видеть ту же информацию. Ему не нужно перемещаться по сайту, чтобы найти этот вопрос.

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

Это примеры архитектуры REST на работе.

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

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

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


Как сказал tweakt, Amazon S3 - хорошая модель для работы. Их сигнатуры запроса имеют некоторые функции (например, включение временной метки), которые помогают защитить как от случайного, так и от вредоносного запроса.

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

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





web-services rest soap architecture