Должны ли веб-службы Netflix или Twitter использовать REST или SOAP?

Ответ 1

Канарейка в угольной шахте.

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

Предупреждающие знаки

Вы абсолютно правы, для создания клиентов RESTful требуется больше времени, чем клиенты SOAP. Инструментарий SOAP отнимает много кода шаблона и делает объекты клиентского прокси доступными практически без усилий. С помощью инструмента, такого как Visual Studio и URL-адреса сервера, я могу получить доступ к удаленным объектам произвольной сложности, локально через менее чем пять минут.

Службы, которые возвращают приложение /xml и application/json, настолько раздражают разработчиков-клиентов. Что мы должны делать с этим блоком данных?

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

Накладные расходы SOAP, га. Его латентность, которая убивает. Если люди действительно обеспокоены количеством лишних байтов, проходящих через провод, то, возможно, HTTP не является правильным выбором. Вы видели, сколько байтов используется заголовком user-agent?

Да, вы когда-нибудь пробовали использовать веб-браузер в качестве инструмента отладки для чего-либо, кроме HTML и javascript. Поверьте мне, это отстой. Вы можете использовать только два глагола, кеширование постоянно мешает, обработка ошибок поглощает столько информации, что постоянно ищет проклятый favicon.ico. Просто стреляй в меня.

Читаемый URL. Только существительные, не глаголы. Да, это так просто, пока мы выполняем только операции CRUD, и нам нужно только получить доступ к иерархии объектов одним способом. К сожалению, для большинства приложений требуется немного больше функциональности.

Надвигающаяся катастрофа

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

Тем не менее, они находят, что управление версиями является такой же проблемой, но компилятор не помогает обнаруживать проблемы. Письменный клиентский код - это боль, которую нужно поддерживать, когда структуры данных развиваются, а URL-адреса получают рефакторинг. Проектирование API вокруг только существительных и четырех глаголов может быть очень тяжелым, особенно с реестрами RESTful Url, которые сообщают вам, когда вы можете и не можете использовать строки запроса.

Разработчики начнут спрашивать, почему мы тратим наши усилия на поддержку форматов Json и форматов Xml, почему бы не просто сосредоточить наши усилия на одном и сделать это хорошо?

Как все пошло не так.

Скажите, что пошло не так. Мы, как разработчики, позволили отделам маркетинга воспользоваться нашей основной слабостью. Наш вечный поиск серебряной пули ослепил нас реальностью того, что НАХОДИТ на самом деле. Поверхность REST кажется такой простой и простой. Назовите свои ресурсы URL-адресами и используйте GET, PUT, POST и DELETE. Черт, у нас разработчики уже знают, как это сделать, мы работаем с базами данных в течение многих лет, которые имеют таблицы и столбцы и операторы SQL, которые имеют SELECT, INSERT, UPDATE и DELETE. Это должен был быть кусок пирога.

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

Эта политая версия REST во многих отношениях была подтверждена в культуре разработчиков. Были созданы серверные рамки, которые поощряли идентификацию ресурсов и единый интерфейс, но не помогли другим ограничениям. Термины начали плавать вокруг дифференциации подходов (HI-REST против LO-REST, Corporate REST и Academic REST, REST против RESTful).

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

REST, этот термин определенно стал основным. Почти каждый основной веб-ресурс, имеющий API, поддерживает "REST". Twitter и Netflix - два очень высокого уровня. Страшно то, что я могу думать только об одном публичном API, который является самоописательным, и есть горстка, которая действительно реализует ограничение гипермедиа. Конечно, некоторые сайты, такие как StackOverflow и Gowalla, поддерживают ссылки в своих ответах, но в их ссылках есть огромные дыры. У StackOverflow API нет корневой страницы. Представьте, насколько успешным был бы веб-сайт, если бы не была домашняя страница для веб-сайта!

Вы были введены в заблуждение Im fear

Если вы сделали это так далеко, короткий ответ на ваш вопрос - это те API (Netflix и Twitter), которые не соответствуют всем ограничениям, и поэтому вы не получите преимуществ, которые должны принести REST apis.

Клиенты REST занимают больше времени, чем SOAP-клиенты, но не привязаны к одному конкретному сервису, поэтому вы должны иметь возможность повторно использовать их через службы. Возьмем классический пример веб-браузера. Сколько услуг может получить доступ к веб-браузеру? Как насчет Feed Reader? Теперь, сколько различных сервисов может получить доступ к среднему клиенту Twitter? Да, только один.

Клиенты REST не должны создаваться для взаимодействия с одной службой, они должны быть созданы для обработки определенных типов носителей, которые могут обслуживаться любой службой. Очевидным вопросом является то, как вы можете создать клиент REST для службы, которая предоставляет приложение /json или application/xml. Ну, вы не можете. То потому что эти форматы совершенно бесполезны для клиента REST. Вы сами это сказали,

вы должны сделать "догадки" относительно того, что вернется через трубу, как нет реальной схемы или ссылки документ

Вы абсолютно правы для таких сервисов, как Twitter. Однако самоописательное ограничение в REST говорит о том, что заголовок типа HTTP-содержимого должен точно описывать содержимое, которое передается по проводу. Доставка приложения /json и application/xml ничего не сообщает о содержании.

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

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

Ваш последний пункт о читаемых URL-адресах является самым ироничным. Если вы действительно выполняете ограничение гипермедиа, каждый URL-адрес может быть GUID, и клиентский разработчик ничего не потеряет в удобочитаемости.

Тот факт, что URI должен быть непрозрачным для клиента, является одним из самых важных при разработке систем REST. Читаемые URL-адреса удобны для разработчика сервера, а хорошо структурированные URL-адреса упрощают отправку запросов на серверную инфраструктуру, но это детали реализации, которые не должны влиять на разработчиков, потребляющих API.

API Twitter не близок к тому, чтобы быть RESTful, и поэтому вы не можете увидеть какую-либо выгоду от его использования над SOAP. API Netflix намного ближе, но использование универсальных типов носителей демонстрирует, что неспособность придерживаться даже одного ограничения может оказать глубокое влияние на преимущества, получаемые от службы.

Возможно, это не их вина

Я сделал много демпинга на провайдерах услуг, но требуется два танца RESTfully. Служба может следовать за всеми ограничениями религиозно, и клиент все еще может легко отменить все преимущества.

Если клиентские жесткие коды запрашивают доступ к определенным типам ресурсов, это мешает серверу изменять эти URL-адреса. Конструкция любого вида URL-адресов, основанная на неявном знании того, как структура службы создает свои URL-адреса, является нарушением.

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

Должны ли они использовать SOAP?

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

Ответ 2

SOAP - это объектно-ориентированный, удаленный вызов процедур. Он работает, создавая новую абстракцию поверх существующего протокола (HTTP).

REST - это ориентированный на документ подход, который просто использует функции существующего протокола (HTTP). "REST" - просто модное слово - концепция такова: просто используйте веб-интерфейс так, как он был разработан для работы!

В ответ на внесенные изменения:

• "Реализация службы REST выполняется бесконечно дольше, чем реализация SOAP-сервиса".

  Um, нет, он не может быть бесконечно длиннее. И в тех случаях, когда вы пытаетесь получить уже документ или файл, он на самом деле намного быстрее. Например, спецификация OGC для WMS (Web Mapping Service) определяет как SOAP, так и REST версию протокола, и есть причина, по которой почти никто не реализует SOAP-версию, потому что, если вы пытаетесь получить карту, это намного проще просто создать URL-адрес и получить изображения байтов из этого URL-адреса, чем это нужно для инкапсуляции в сообщение SOAP. Но да, я соглашусь, что если точкой веб-службы является передача некоторого сильно типизированного объекта в объектной модели домена, SOAP лучше подходит для этого использования.

• "Зачем писать службу REST, которая все равно возвращает XML?"

  Ну, да, это может быть глупо. Но это зависит от того, что такое XML. Если там есть определенная схема, то нет никакой двусмысленности. Например, вы можете думать, что URL-адреса WSDL являются своего рода веб-службой RESTful для получения информации о веб-службе. В этом случае добавление служебных данных другого запроса SOAP будет бессмысленным.

  В общем, REST выигрывает, когда передаваемый контент можно рассматривать как файл , как отдельный элемент. SOAP выигрывает, когда содержимое должно рассматриваться как объект с членами.

• "Я слышал жалобу на то, что с SOAP у вас есть" накладные расходы "в конверте SOAP. В этот день и возраст нам действительно нужно беспокоиться о нескольких байтах?"

  Да. Не в любых обстоятельствах, но есть сайты с большим количеством трафика, где это имеет значение. Достаточно ли разницы перевесить семантические различия использования SOAP вместо REST? Я сомневаюсь в этом. Если вы делаете протокол удаленного доступа к объекту и количество байтов делает разницу, SOAP, вероятно, не является для вас инструментом - возможно, вы должны использовать CORBA или DCOM.

• "Я слышал аргумент, что с помощью REST вы можете просто поместить URL-адрес в браузер и посмотреть данные".

  Да, и это большой аргумент в пользу REST , если имеет смысл просматривать данные в браузере. Например, с данными изображения, это простой способ отладки службы - просто вставьте URL-адрес в адресную строку браузера и посмотрите, как выглядит изображение. Или, если возвращаемые данные находятся в XML, и у вас есть ссылка на таблицу стилей XML, которая отображается в читаемом HTML в браузере, тогда вы получаете преимущества семантической разметки и простой визуализации всего в одном пакете. Но вы правы, это преимущество в основном испаряется при работе с более сложными схемами аутентификации. Если вы не можете закодировать всю свою информацию аутентификации в каждом HTTP-запросе, я бы сказал, что она вообще не считается REST.

• "Зачем нам нужен" читаемый "URL-адрес для каждого ресурса? Если мы использовали инструмент для реализации службы, действительно ли мы заботимся о фактическом URL-адресе?"

  Ну, это зависит. Почему нам нужны читаемые URL-адреса для любого ресурса в Интернете? Вы можете прочитать эссе Тима Бернерса-Ли Cool URIs Do not Change для обоснования, но в основном, пока ресурс может по-прежнему быть полезен в будущем, URI для этого ресурса должен оставаться неизменным.

  Очевидно, что для временных ресурсов (например, ссылка "Сегодня деньги" в эссе) нет необходимости в этом, так как необходимость ссылки на ресурс исчезает, если соответствующий ресурс уходит. Но для более постоянных ресурсов (например, вопросов StackOverflow, например, или фильмов в IMDB) вы хотите иметь URL-адрес, который будет работать вечно. Когда вы разрабатываете веб-сервис, вам нужно решить, могут ли сами ресурсы пережить вашу услугу, и если да, то REST, вероятно, правильный путь.

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

Короче говоря: REST и SOAP - это просто инструменты. У каждого из них есть свои сильные и слабые стороны. Если единственный инструмент у вас есть молот, то каждая проблема выглядит как гвоздь. Поэтому ознакомьтесь с обоими инструментами и научитесь правильно их использовать, а затем выберите подходящий инструмент для каждой работы.

Ответ 3

Честный вопрос заслуживает честного ответа. Но во-первых, почему вы использовали текст этого вопроса как ответ на другой вопрос, если вы не считаете его риторическим в природе?

В любом случае:

• " Инструменты существуют для всех современных языков/фреймворков/платформ для чтения в WSDL и вывода прокси-классов и клиентов. Реализация службы REST выполняется вручную, читая документацию."

  Как и поставщики браузеров, прочитали и перечитали спецификацию HTML 4.01 вверх и вниз, чтобы попытаться реализовать последовательный просмотр. Вы размышляли о том, что браузеры были изобретены задолго до интернет-банкинга и stackoverflow, и все же вы можете использовать браузер, чтобы делать именно эти вещи. Это стало возможным благодаря единственной причине, что все согласны использовать HTML (и связанные с ним форматы, такие как CSS, JS, JPEG и т.д.).

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

  Но для Twitter и Netflix нет универсального соглашения о том, что "все существующие в мире микроблоги должны использовать приложение/твиттер типа мультимедиа", главным образом потому, что микроблоги являются настолько новыми. Возможно, через несколько лет несколько сервисов микроблогов согласуются с одним и тем же API, чтобы Twitter, Facebook, Identica и могли взаимодействовать. Ни один из их существующих API нигде не находится рядом с RESTful, как бы они ни требовали, поэтому я не ожидаю, что это произойдет в ближайшее время.

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

  Вы ударили ноготь по голове. REST - все о распределенных и гипермедиях, и это в значительной степени подводит итог. Браузер смотрит на то, что получает от запроса, и показывает его пользователю. HTML-страница обычно генерирует намного больше запросов GET, например CSS, скриптов и изображений. Изображение обычно отображается только на экране, выполняется JavaScript, и так далее. Каждый раз браузер делает то, что он делает, потому что он нашел ссылку в теге <img> или <style>, а тип материала ответа - image/jpeg или text/css.

  Если Twitter использует API, основанный на гипермедиа, он, вероятно, всегда будет возвращать application/tweet каждый раз, когда вы будете следовать ссылке на твит, но клиент не должен его принимать, и всегда проверяйте, что он делает, прежде чем действовать на него.

• " Зачем писать службу REST, которая возвращает XML в любом случае?"

  Все это сводится к типам носителей. Как и HTML, если вы видите элемент, который вы не знаете, что на самом деле означает, спецификация HTML указывает вам игнорировать их и обрабатывать "тело" тега, если он есть. Аналогично, спецификация атома указывает вам игнорировать неизвестные элементы и внешнюю разметку (из разных пространств имен), а не обрабатывать тело (IIRC).

  Проектирование типов носителей для общих проблемных доменов (как и в формате HTML для проблемного домена с богатым текстом) очень сложно. Создание типов носителей для очень узких проблемных областей, вероятно, намного проще (например, чириканье). Но всегда рекомендуется разрабатывать расширяемость и определять, как клиенты (и серверы) должны реагировать, когда видят элементы или элементы данных, которые не соответствуют спецификации. JPEG, например, имеет тип записи, специфичный для приложения (например, APP1), который используется для хранения всех видов метаданных.

• " Я слышал жалобу о том, что с SOAP у вас есть" накладные расходы "в конверте SOAP. В этот день и возраст нам действительно нужно беспокоиться о нескольких байтах?"

  Нет, нет. REST - это абсолютно не то, чтобы быть эффективным по отношению к проводу, он действительно эффективен с эффективностью проводки. Эффективность REST исходит из возможностей кэширования, разрешенных всеми другими ограничениями: Fielding диссертацияпримечания: Компромисс, однако, состоит в том, что унифицированный интерфейс снижает эффективность, поскольку информация передается в стандартизованной форме, а не в той, которая специфична для потребностей приложения. Интерфейс REST предназначен для эффективной передачи данных гипермедиа с крупными зернами, оптимизации для общего случая Интернета, но в результате чего интерфейс не является оптимальным для других форм взаимодействия с архитектурой. Я не думаю, что счетчик байтов SOAP Envelope считается достоверным.

• " Я слышал аргумент, что с помощью REST вы можете просто поместить URL-адрес в браузер и посмотреть данные."

  Да, это также неверный аргумент. Это не работает. Даже если это сработало, большинство узких API-интерфейсов REST используют типы носителей, о которых браузеры понятия не имеют и все еще не работают.

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

• " Зачем нам нужен" читаемый "URL-адрес для каждого ресурса? Если мы использовали инструмент для реализации службы, действительно ли мы заботимся о фактическом URL-адресе?"

  Если вы посмотрите, как работает веб-сайт, я уверен, что люди в целом рады, что URI для страницы wikipedia выглядит так: http://en.wikipedia.org/wiki/Stack_overflow вместо http://en.wikipedia.org/wiki/?oldid=376349090. Но на самом деле это не важно для REST. Важная вещь, чтобы попытаться получить право - это выбрать размещение соответствующих данных в URI, который вряд ли изменится. Вы можете подумать, что идентификатор базы данных никогда не изменится, но что произойдет, когда два набора данных необходимо объединить? Все первичные ключи меняются. Заголовок страницы (Stack_overflow) не изменится.

Извините за длинный ответ, но я считаю, что этот вопрос действителен и не был рассмотрен до этого на SO. Я уверен, что Даррел Миллер добавит свой ответ, как только он вернется.

Изменить: форматирование

Ответ 4

У Мартина Фаулера есть пост в модели зрелости Ричардсона, который отлично справляется с объяснением разницы между SOAP и REST.

Ответ 5

WSDL и другие протоколы уровня документа являются избыточными. Протокол HTTP поддерживает гораздо более богатый набор операций, помимо всего лишь подачи документов и отправки форм.

Сторонники REST неудобны для этой избыточности.