Должен ли веб-сервис Netflix или Twitter использовать REST или SOAP? [закрытый]
я реализовал две службы REST: Twitter и Netflix. Оба раза я изо всех сил пытался найти использование и логику, связанную с решением выставить эти службы как REST вместо SOAP. Я надеюсь, что кто-то может подсказать мне, чего мне не хватает, и объяснить, почему REST использовался в качестве реализации службы для таких служб.
1) реализация службы REST занимает бесконечно больше времени, чем реализация службы SOAP. Инструменты существуют для всех современных языков / фреймворков / платформ читать в WSDL и выводить прокси-классы и клиенты. Реализация службы REST выполняется вручную и - получить это-путем чтения документации. Кроме того, при реализации этих двух сервисов вы должны сделать "догадки" о том, что вернется через канал, поскольку нет реальной схемы или справочного документа.
2) Зачем писать службу REST, которая возвращает XML в любом случае? Единственное различие заключается в том, что с REST вы не знаете типы, которые представляет каждый элемент / атрибут - вы находитесь на своем самостоятельно реализовать его и Надежда что однажды строка не попадается в поле, которое, как вы думали, всегда было int. SOAP определяет структуру данных с помощью WSDL, поэтому это не проблема.
3) я слышал жалобу, что с мылом у вас есть "накладные расходы" мыльного конверта. В этот день и возраст, нам действительно нужно беспокоиться о кучке байтов?
4) я слышал аргумент, что с REST вы можете просто вставить URL-адрес в браузер и посмотреть данные. Конечно, если ваша служба REST использует простую аутентификацию или нет. Например, служба Netflix использует OAuth, которая требует, чтобы вы подписывали вещи и кодировали вещи, прежде чем вы даже сможете отправить свой запрос.
5) Зачем нам нужен "читаемый" URL для каждого ресурса? Если бы мы использовали инструмент для реализации сервиса, действительно ли мы заботимся о фактическом URL?
5 ответов:
канарейка в угольной шахте.
Я ждал такого вопроса уже почти год. Этот день неизбежно наступит, и я уверен, что в ближайшие месяцы мы увидим еще много подобных вопросов.
предупреждающие знаки
вы абсолютно правы, это занимает больше времени, чтобы построить RESTful клиентов, чем клиентов SOAP. Наборы инструментов SOAP забирают много шаблонного кода и делают клиента прокси-объекты доступны практически без усилий. С помощью такого инструмента, как Visual Studio и URL-адрес сервера, я могу получить доступ к удаленным объектам произвольной сложности локально менее чем за пять минут.
службы, которые возвращают application/xml и application / json, так раздражают разработчиков клиентов. Что мы должны делать с этим сгустком данных?
к счастью, многие сайты, предоставляющие услуги REST, также предоставляют множество клиентских библиотек, чтобы мы могли использовать эти библиотеки чтобы получить доступ к строго типизированные объекты. Кажется немного глупым, хотя. Если бы они использовали мыло, мы могли бы сами кодировать эти прокси-классы.
мыло накладные расходы, ха. Это латентность, которая убивает. Если люди действительно обеспокоены количеством лишних байтов, идущих по проводу, то, возможно, HTTP не является правильным выбором. Вы видели, сколько байтов используется заголовком user-agent?
Да, вы когда-нибудь пробовали использовать веб-браузер в качестве инструмента отладки для все, что угодно, кроме HTML и javascript. Поверь мне, это отстой. Вы можете использовать только два глагола, кэширование постоянно мешает, обработка ошибок поглощает так много информации, она постоянно ищет проклятый фавикон.ico. Просто пристрели меня.
читаемый URL. Только существительные, никаких глаголов. Да, это легко, пока мы выполняем только операции CRUD, и нам нужно только получить доступ к иерархии объектов одним способом. К сожалению, большинству приложений нужно немного больше функциональность, чем это.
надвигающуюся катастрофу
есть метрическая лодка разработчиков, которые в настоящее время разрабатывают приложения, которые интегрируются со службами REST, которые находятся в процессе прихода к тому же набору выводов, которые у вас есть. Им обещали простоту, гибкость, масштабируемость, эволюционность и Святой Грааль счастливого повторного использования. Характеристики самой сети, как все может пойти не так.
однако, они обнаружение этой версии является такой же проблемой, но компилятор не помогает обнаруживать проблемы. Рукописные код клиента является боль, чтобы сохранить данные развиваются структуры и урлов сделать рефакторинг. Проектирование API вокруг только существительных и четырех глаголов может быть очень сложным, особенно с RESTful url-фанатиками, которые говорят вам, когда вы можете и не можете использовать строки запроса.
разработчики собираются начать спрашивать, почему мы тратим наши усилия на поддержку форматов Json и Xml, почему не просто сосредоточиться на одном и сделать это хорошо?
Как все пошло не так
Я скажу вам, что пошло не так. Мы как разработчики позволяем маркетинговым отделам воспользоваться нашей основной слабостью. Наш вечный поиск серебряной пули ослепил нас к реальности того, что такое покой на самом деле. На поверхности отдых кажется таким легким и простым. Назовите свои ресурсы URL-адресами и используйте GET, PUT, POST и DELETE. Черт, мы, разработчики, уже знаем, как это сделать, у нас есть в течение многих лет я имел дело с базами данных, которые имеют таблицы и столбцы, а также инструкции SQL, которые имеют SELECT, INSERT, UPDATE и DELETE. Это должен был быть кусок пирога.
есть и другие части REST, которые некоторые люди обсуждают, такие как самоописание и ограничение гипермедиа, но эти ограничения не так просты, как идентификация ресурсов и единый интерфейс. Кажется, чтобы добавить сложность, где желаемой целью является простота.
это разбавляется версия REST стала проверенной в культуре разработчиков во многих отношениях. Были созданы серверные фреймворки, которые поощряли идентификацию ресурсов и единый интерфейс, но ничего не делали для поддержки других ограничений. Термины начали плавать вокруг дифференциации подходов (HI-REST vs LO-REST, корпоративный отдых vs Академический отдых, отдых против отдыха).
несколько человек кричат, что если вы не применяете все ограничения, это не отдых. Вы не получите преимущества. Нет половина отдыха. Но эти голоса были помечены как религиозные фанатики, которые были расстроены тем, что их драгоценный термин был украден из безвестности и стал мейнстримом. Ревнивые люди, которые пытаются сделать отдых более трудным, чем он есть.
отдых, термин, определенно стал мейнстримом. Почти каждое крупное веб-свойство, которое имеет API, поддерживает "REST". Twitter и Netflix-это два очень высоких профиля. Страшно то, что я могу только думать об одном публичном API, который является информативным и есть несколько, которые действительно реализуют ограничение гипермедиа. Конечно, некоторые сайты, такие как StackOverflow и Gowalla, поддерживают ссылки в своих ответах, но в их ссылках есть огромные зияющие дыры. API StackOverflow не имеет корневой страницы. Представьте себе, насколько успешным был бы веб-сайт, если бы не было домашней страницы для веб-сайта!
боюсь, Вы были введены в заблуждение
Если вы сделали это так далеко, короткий ответ на ваш вопрос - это те API (Netflix и Twitter) не соответствуют всем ограничениям, и поэтому вы не получите преимущества, которые должны принести API REST.
клиенты REST требуют больше времени для сборки, чем клиенты SOAP, но они не привязаны к одной конкретной службе, поэтому вы должны иметь возможность повторно использовать их в разных службах. Возьмем классический пример, веб-браузер. Сколько служб может получить доступ к веб-браузеру? А как насчет читателя ленты? Теперь, сколько различных услуг может получить средний клиент Twitter? Да, только один.
клиенты REST не должны быть построены для взаимодействия с одной службой, они должны быть построены для обработки определенных типов носителей, которые могут обслуживаться любой службой. Очевидный вопрос заключается в том, как вы можете построить клиент REST для службы, которая предоставляет application/json или application/xml. Ну, вы не можете, потому что эти форматы совершенно бесполезны для клиента REST. Ты сам это сказал,
вы должны сделать "догадки" как вернусь через трубу нет никакой реальной схемы или ссылки документ
вы абсолютно правы для таких сервисов, как Twitter. Однако описательные ограничения, в остальном говорит, что заголовок типа содержимого http должны точно описать контент, который передается по сети. Доставка application/json и application / xml ничего не говорит о содержимом.
когда дело доходит до рассмотрения результативность Системы, основанные на отдыхе, необходимо смотреть на более широкую картину. Разговор о байтах конверта похож на разговор о разматывании цикла при сравнении быстрой сортировки с сортировкой оболочки. Существуют сценарии, где мыло может выполнять лучше, и есть сценарии, где остальные могут работать лучше. Контекст-это все.
REST получает большую часть своего преимущества в производительности, будучи очень гибким в отношении того, какие типы носителей он поддерживает, и имея сложную поддержку кэширования. Для кэширования, чтобы хорошо работать хотя почти все ограничения должны быть соблюдены.
ваш последний пункт о читаемых URL-адресах, безусловно, самый ироничный. Если вы действительно привязаны к ограничению гипермедиа, то каждый URL-адрес может быть GUID, и разработчик клиента ничего не потеряет в удобочитаемости.
тот факт, что URI должны быть непрозрачными для клиента, является одной из самых ключевых вещей при разработке систем REST. Читаемые URL-адреса удобны для разработчика сервера, а хорошо структурированные URL-адреса облегчают работу для серверной платформы для отправки запросов, но это детали реализации, которые не должны влиять на разработчиков, потребляющих API.
API Twitter даже не близок к тому, чтобы быть спокойным, и именно поэтому вы не можете видеть никакой пользы от его использования над SOAP. API Netflix намного ближе, но использование общих типов носителей демонстрирует, что неспособность придерживаться даже одного ограничения может оказать глубокое влияние на преимущества, полученные от услуга.
возможно, это не все их вина
Я сделал много демпинга на поставщиков услуг, но это занимает два, чтобы танцевать спокойно. Служба может следовать всем ограничениям религиозно, и клиент все еще может легко отменить все преимущества.
Если клиент жестко кодирует URL-адреса для доступа к определенным типам ресурсов, то это предотвращает сервер от изменения этих URL-адресов. Любая конструкция URL-адреса, основанная на неявном знании того, как сервис структурирует свои URL-адреса-это нарушение.
предположения о том, какой тип представления будет возвращен из ссылки, могут привести к проблемам. Создание предположений о содержании представления, основанного на знаниях, которые явно не указаны в заголовках HTTP, определенно создаст связь, которая вызовет боль в будущем.
должны ли они использовать мыло?
лично я так не думаю. Остальное сделано правильно позволяет распределенной системе развиваться в долгосрочной перспективе. Если вы строите распределенные системы, которые имеют компоненты, разработанные разными людьми и должны длиться в течение многих лет, то отдых-довольно хороший вариант.
мыло-это объектно-ориентированное,удаленный вызов процедур стек технологий. Он работает путем построения новой абстракции поверх существующего протокола (HTTP).
отдых-это ориентированный документ подход, который просто использует возможности существующего протокола (HTTP). "Отдых" - это просто модное слово - концепция такова: просто используйте сеть так, как это было предназначен работать!
в ответ на изменения вопрос:
" реализация службы REST занимает бесконечно больше времени, чем реализация службы SOAP."
Эм, нет, этого не может быть!--9-->бесконечно больше. И в тех случаях, когда то, что вы пытаетесь получить уже документ или файл, это на самом деле быстрее. Например, спецификация OGC для WMS (Web Mapping Service) определяет как SOAP, так и REST-версию протокола, и есть причина почему почти никто не реализует версию SOAP - это потому, что если вы пытаетесь получить карту, гораздо проще просто построить URL-адрес и извлечь байты изображения из этого URL-адреса, чем беспокоиться о его инкапсуляции в сообщение SOAP. Но да, я соглашусь, что если целью веб-службы является передача некоторого строго типизированного объекта в объектной модели домена, SOAP лучше подходит для этого использования.
" зачем писать службу REST, которая возвращает XML так или иначе?"
Ну да, это может быть глупо. Но это зависит от того, что такое XML. Если есть четко определенная схема для него где-то, то нет никакой двусмысленности. Например, URL-адреса WSDL можно рассматривать как своего рода веб-службу RESTful для получения информации о веб-службе. В этом случае добавление накладных расходов другого запроса SOAP было бы бессмысленным.
В общем, REST выигрывает, когда передаваемый контент можно рассматривать как файл, как единое целое. SOAP выигрывает, когда содержимое должно рассматриваться как объект с членами.
да. Не в каждом случае, но есть сайты с большим количеством трафика, где это имеет значение. Достаточно ли этого разница перевешивает семантические различия использования мыла вместо отдыха? Я сомневаюсь в этом. Если вы делаете протокол удаленного доступа к объекту, и количество байтов имеет значение, SOAP, вероятно, не является инструментом для вас в любом случае-возможно, вы должны использовать CORBA или DCOM вместо этого.
да, и это большой аргумент в пользу отдыха если есть смысл просматривать данные в браузере. Например, с данными изображения это простой способ отладки службы - просто вставьте URL-адрес в адресную строку браузера и посмотрите, как выглядит изображение. Или, если возвращаемые данные находятся в XML, и у вас есть ссылка на таблицу стилей XML, которая отображается в читаемом HTML в браузере, то вы получаете преимущество семантической разметки и простой визуализации в одном пакете. Но вы правы, это благо в основном испаряется при работе с более сложными схемами аутентификации. Если вы не можете кодируйте всю свою аутентификационную информацию в каждый HTTP-запрос, то я бы сказал, что это вообще не считается отдыхом.
"зачем нам нужен" читаемый " URL для каждого ресурса? Если бы мы использовали инструмент для реализации сервиса, действительно ли мы заботимся о фактическом URL?"
Ну, это зависит от. Зачем нам нужны читаемые URL-адреса для любого ресурс в сети? Вы можете прочитать эссе Тима Бернерса-Ли крутые Ури не меняются для обоснования, но в основном, пока ресурс может быть полезен в будущем, URI для этого ресурса должен оставаться прежним.
для записи, да, я разрабатывал веб-страницы задолго до того, как NetFlix или Twitter существовали. И нет, у меня еще не было никакой необходимости или возможности реализовать клиента либо NetFlix, либо сервисы Twitter. Но даже если с их услугами ужасно трудно работать, это не означает, что технология, на которой они реализовали свои услуги, плоха-только то, что эти две реализации плохи.
короче говоря: отдых и мыло - это просто инструменты. У каждого из них есть свои сильные и слабые стороны. Если единственным инструментом является молоток, то каждая проблема кажется гвоздем. Поэтому познакомьтесь с обоими инструментами и узнайте, как их использовать их правильно, а затем выбрать правильный инструмент для каждой работы.
честный вопрос заслуживает честного ответа. Но сначала, почему вы использовали текст этого вопроса как ответ на другой вопрос если бы вы не думали, что это было риторическим по своей природе?
в любом случае:
"инструменты существуют для всех современных языков/фреймворков/платформ для чтения в WSDL и вывода прокси-классов и клиентов. Реализация службы REST выполняется вручную путем чтения документации."
так же, как поставщики браузеров читали и перечитывали спецификацию HTML 4.01 вверх и вниз, чтобы попытаться реализовать согласованный опыт просмотра. Задумывались ли вы о том, что браузеры были изобретены задолго до интернет-банкинга и StackOverflow, и все же, вы можете использовать браузер, чтобы делать только те вещи. Это стало возможным только потому, что все согласны использовать HTML (и связанные с ним форматы, такие как CSS, JS, JPEG и т. д.).
Блоги на самом деле нет это новое, и кто-то придумал AtomPub, который позволяет любому программному обеспечению для ведения блога получать доступ и обновлять сообщения в блоге, так же как любой веб-браузер может получить доступ к любой веб-странице. Это довольно аккуратно и работает из-за ограничений RESTful, наложенных протоколом.
но для Twitter и Netflix нет универсального соглашения о том, что" все существующие микроблоги должны использовать приложение типа медиа/твит", главным образом потому, что микроблоги настолько новы. Может быть, через несколько лет несколько сервисы микроблогов располагаются на одном API, так что Twitter, Facebook, Identica и могут взаимодействовать. Ни один из их существующих API-интерфейсов не близок к RESTful, как бы они ни утверждали, поэтому я не ожидаю, что это произойдет очень скоро.
"кроме того, при реализации этих двух служб, вы должны сделать "догадки" о том, что будет возвращаться через трубу, поскольку нет реальной схемы или справочного документа."
вы попали в самую точку. Остальное все о распределенных и гипермедиа, и это в значительной степени подводит итог. Браузер смотрит на то, что он получает от запроса и показывает его пользователю. HTML-страница обычно порождает гораздо больше запросов GET, например CSS, скрипты и изображения. Изображение обычно выводится только на экран, выполняется JavaScript и так далее. Каждый раз браузер делает то, что он делает, потому что он нашел ссылку в
<img>или<style>тег и тип носителя ответа былimage/jpegилиtext/css.если Twitter делает API на основе гипермедиа, он, вероятно, всегда будет возвращать
application/tweetкаждый раз, когда вы переходите по ссылке на твит, но клиент никогда не должны предположить это, и всегда проверяйте, что он получает, прежде чем действовать на него."зачем писать службу REST, которая возвращает XML в любом случае?"
все это сводится к типам СМИ. Как и HTML, если вы видите элемент, который вы понятия не имеете, что на самом деле означает, спецификация HTML предписывает вам игнорировать их, и обработайте "тело" тега, если он есть. Аналогично, спецификация atom предписывает вам игнорировать неизвестные элементы и внешнюю разметку (из разных пространств имен) и не обработка тела (IIRC).
проектирование типов носителей для общих проблемных областей (как в HTML тип носителя для rich text проблемная область) очень сложно. Создание типов носителей для очень узких проблемных доменов, вероятно, намного проще (например, твит). Но это всегда хорошая идея разработать расширяемость и указать, как клиенты (и серверы) должны реагировать, когда они видят элементы или элементы данных, которые не соответствуют спецификации. JPEG, например, имеет специфичный для приложения тип записи (например, APP1), который используется для хранения всех видов метаданных.
"я слышал жалобу, что с мылом у вас есть "накладные расходы" мыльного конверта. В этот день и возраст, нам действительно нужно беспокоиться о кучке байты?"
нет, мы не знаем. Остальное абсолютно не эффективным по проводу, это на самом деле торговая эффективности проволоки. Эффективность REST исходит из возможностей кэширования, включенных всеми другими ограничениями:диссертация Филдинга Примечания: я не думаю, что накладные расходы на подсчет байтов конверта SOAP являются допустимой проблемой.
"я слышал аргумент, что с REST вы можете просто вставить URL-адрес в браузер и посмотреть данные."
да, это также недопустимый аргумент. Это не работает таким образом. Даже если это сработает, большинство узкий REST API там используют типы носителей, о которых браузеры понятия не имеют, и он все равно не будет работать.
но есть гораздо больше возможностей, чем браузер для тестирования API на основе HTTP, таких как утилиты командной строки или расширения браузера, которые позволяют вам контролировать почти любой аспект HTTP-запроса, проверять заголовки ответов и обнаруживать ссылки для вас. Но даже так, это это далеко не так просто, как создание заглушек WSDL и создание трехстрочной программы для вызова функции в любом случае.
"зачем нам нужен" читаемый " URL для каждого ресурса? Если бы мы использовали инструмент для реализации сервиса, действительно ли мы заботимся о фактическом URL?"
если вы посмотрите на то, как работает сеть, я уверен, что люди по большому счету рады, что URI для страницы Википедии выглядит так,
http://en.wikipedia.org/wiki/Stack_overflowвместоhttp://en.wikipedia.org/wiki/?oldid=376349090. Но это на самом деле не важно отдыхать. Важно попытаться сделать правильный выбор, чтобы разместить соответствующие данные в URI, который вряд ли изменится. Можно подумать, что идентификатор базы данных никогда не изменится, но что происходит, когда два набора данных должны быть объединены? Все ваши первичные ключи меняются. Заголовок страницы (Stack_overflow) не изменится.извините за длинный ответ, но я считаю, что этот вопрос является действительным, и не был рассмотрен здесь раньше. Я уверен, что Даррел Миллер добавит свой ответ, как только он вернется.
изменить: форматирование
У Мартина Фаулера есть сообщение о модели зрелости Ричардсона который отлично объясняет разницу между мылом и отдыхом.