Я реализовал два сервиса REST: Twitter и Netflix. Оба раза я изо всех сил пытался найти применение и логику, связанные с решением выставить эти сервисы как REST вместо SOAP. Я надеюсь, что кто-нибудь может подсказать мне, что мне не хватает, и объяснить, почему REST использовался в качестве реализации сервиса для таких сервисов, как эти.
Реализация службы REST занимает бесконечно больше времени, чем реализация службы SOAP. Существуют инструменты для чтения всеми современными языками / средами / платформами в WSDL и вывода прокси-классов и клиентов. Внедрение службы REST осуществляется вручную и - получается - читая документацию. Более того, при реализации этих двух сервисов вы должны «угадать», что будет возвращаться через канал, поскольку нет реальной схемы или справочного документа.
Зачем писать REST-сервис, который все равно возвращает XML? Единственное отличие состоит в том, что с REST вы не знаете типов, которые представляет каждый элемент / атрибут, - вы сами можете его реализовать и надеетесь, что однажды строка не попадет в поле, которое вы считали всегда int. SOAP определяет структуру данных с использованием WSDL, так что это не сложно.
Я слышал жалобу, что с SOAP у вас есть «накладные расходы» на конверт SOAP. В наши дни, действительно ли нам нужно беспокоиться о горстке байтов?
Я слышал аргумент, что с REST вы можете просто вставить URL-адрес в браузер и посмотреть данные. Конечно, если ваша служба REST использует простую аутентификацию или не использует ее. Сервис Netflix, например, использует OAuth, который требует, чтобы вы подписывали и кодировали вещи, прежде чем вы даже сможете отправить свой запрос.
Зачем нам нужен «читаемый» URL для каждого ресурса? Если бы мы использовали инструмент для реализации сервиса, действительно ли мы заботимся о реальном URL?
Ответы:
Канарейка в угольной шахте.
Я ждал такого вопроса вот уже почти год. Это был неизбежный день, и я уверен, что в ближайшие месяцы мы увидим еще много подобных вопросов.
Предупреждающие знаки
Вы абсолютно правы, для создания клиентов RESTful требуется больше времени, чем для клиентов SOAP. Наборы инструментов SOAP убирают много стандартного кода и делают клиентские прокси-объекты доступными практически без усилий. С помощью такого инструмента, как Visual Studio и URL-адрес сервера, я могу получить доступ к удаленным объектам произвольной сложности, локально менее чем за пять минут.
Сервисы, которые возвращают application / xml и application / json, так раздражают разработчиков клиентов. Что мы должны делать с этим блоком данных?
К счастью, многие сайты, предоставляющие службы REST, также предоставляют множество клиентских библиотек, поэтому мы можем использовать эти библиотеки для получения доступа к группе строго типизированных объектов. Кажется, вроде глупо, хотя. Если бы они использовали SOAP, мы могли бы сами создавать эти прокси-классы.
SOAP накладные расходы, га Это задержка, которая убивает. Если люди действительно обеспокоены количеством избыточных байтов, передаваемых по проводам, то, возможно, HTTP - неправильный выбор. Вы видели, сколько байтов используется заголовком пользовательского агента?
Да, вы когда-нибудь пробовали использовать веб-браузер в качестве инструмента отладки для чего-либо, кроме HTML и javascript. Поверь мне, это отстой. Вы можете использовать только два из глаголов, кэширование постоянно мешает, обработка ошибок поглощает так много информации, он постоянно ищет чертовски favicon.ico. Просто застрели меня.
Читаемый URL. Только существительные, без глаголов. Да, это легко, если мы выполняем только операции CRUD и нам нужен только доступ к иерархии объектов. К сожалению, большинству приложений требуется чуть больше функциональности.
Грядущая катастрофа
Существует огромное количество разработчиков, которые в настоящее время разрабатывают приложения, интегрируемые со службами REST, которые находятся в процессе принятия тех же выводов, что и вы. Им обещали простоту, гибкость, масштабируемость, эволюционность и святой Грааль счастливого повторного использования. Характеристики самой сети, как все может пойти не так.
Тем не менее, они находят, что управление версиями является такой же проблемой, но компилятор не помогает обнаруживать проблемы. Рукописный код клиента - это трудная задача для поддержки по мере развития структур данных и реорганизации URL-адресов. Разработка API на основе только существительных и четырех глаголов может быть очень сложной, особенно когда фанатики RESTful Url сообщают вам, когда вы можете и не можете использовать строки запроса.
Разработчики начнут спрашивать, почему мы тратим наши усилия на поддержку форматов Json и Xml, почему бы просто не сосредоточить наши усилия на одном и не сделать это хорошо?
Как все пошло не так
Я скажу тебе, что пошло не так. Мы, как разработчики, позволяем отделам маркетинга воспользоваться нашей основной слабостью. Наш вечный поиск серебряной пули ослепил нас к реальности того, чем на самом деле является REST. На первый взгляд, REST кажется таким легким и простым. Назовите свои ресурсы с помощью URL и используйте GET, PUT, POST и DELETE. Черт, мы, разработчики, уже знаем, как это сделать, мы годами работали с базами данных, в которых есть таблицы и столбцы, и с операторами SQL, которые имеют SELECT, INSERT, UPDATE и DELETE. Это должен был быть кусок пирога.
Есть и другие части REST, которые обсуждают некоторые люди, такие как информативность и ограничение гипермедиа, но эти ограничения не так просты, как идентификация ресурса и унифицированный интерфейс. Кажется, что добавляет сложности, где желаемой целью является простота.
Эта разбавленная версия REST стала проверенной во многих отношениях. Были созданы серверные инфраструктуры, которые поощряли идентификацию ресурсов и унифицированный интерфейс, но ничего не делали для поддержки других ограничений. Условия начали плавать вокруг дифференциации подходов (HI-REST против LO-REST, Корпоративный REST против Академического REST, REST против RESTful).
Некоторые люди кричат, что если вы не применяете все ограничения, это не REST. Вы не получите преимущества. Там нет половины REST. Но эти голоса были помечены как религиозные фанатики, которые были расстроены тем, что их драгоценный термин был украден из мрака и стал мейнстримом. Ревнивые люди, которые пытаются заставить REST звучать сложнее, чем есть.
Термин REST определенно стал мейнстримом. Почти каждый крупный веб-ресурс, имеющий API, поддерживает «REST». Twitter и Netflix - два очень громких. Страшно то, что я могу думать только об одном общедоступном API, который является самоописательным, и есть несколько, которые действительно реализуют ограничение гипермедиа. Конечно, некоторые сайты, такие как StackOverflow и Gowalla, поддерживают ссылки в своих ответах, но в их ссылках есть огромные дыры. У API StackOverflow нет корневой страницы. Представьте, насколько успешным был бы веб-сайт, если бы не было домашней страницы для веб-сайта!
Боюсь, вы были введены в заблуждение
Если вы сделали это далеко, краткий ответ на ваш вопрос заключается в том, что эти API (Netflix и Twitter) не соответствуют всем ограничениям, и, следовательно, вы не получите преимуществ, которые REST apis должен принести.
Для создания клиентов REST требуется больше времени, чем для клиентов SOAP, но они не привязаны к какой-либо одной конкретной службе, поэтому вы должны иметь возможность повторно использовать их в разных службах. Возьмите классический пример веб-браузера. Сколько сервисов может получить доступ к веб-браузеру? А как насчет Feed Reader? Сколько же сервисов может получить средний клиент Twitter? Да, только один.
Предполагается, что REST-клиенты не предназначены для взаимодействия с одним сервисом, они должны быть созданы для обработки определенных типов медиа, которые могут обслуживаться любым сервисом. Очевидный вопрос в том, как создать клиент REST для службы, которая доставляет application / json или application / xml. Ну, ты не можешь. Это потому, что эти форматы совершенно бесполезны для клиента REST. Вы сказали это сами,
Вы абсолютно правы для таких сервисов, как Twitter. Однако самоописательное ограничение в REST говорит о том, что заголовок типа контента HTTP должен точно описывать контент, который передается по проводам. Доставка application / json и application / xml ничего не говорит о контенте.
Когда дело доходит до рассмотрения производительности систем на основе REST, необходимо взглянуть на картину в целом. Говорить о байтах конверта - все равно что говорить о разматывании цикла при сравнении быстрой сортировки с сортировкой оболочки. Есть сценарии, где SOAP может работать лучше, и есть сценарии, где REST может работать лучше. Контекст это все.
REST получает значительное преимущество в производительности благодаря гибкости в отношении поддерживаемых типов носителей и сложной поддержке кэширования. Чтобы кэширование работало хорошо, необходимо соблюдать почти все ограничения.
Ваш последний пункт о читаемых URL-адресах, безусловно, самый ироничный. Если вы по-настоящему привержены ограничению гипермедиа, то каждый URL может быть GUID, и разработчик клиента ничего не потеряет в удобочитаемости.
Тот факт, что URI должны быть непрозрачными для клиента, является одной из самых важных вещей при разработке систем REST. Читаемые URL-адреса удобны для разработчика сервера, а хорошо структурированные URL-адреса облегчают для серверной среды отправку запросов, но это детали реализации, которые не должны влиять на разработчиков, использующих API.
API Twitter даже близко не подходит для RESTful, и поэтому вы не видите никакой выгоды от его использования по сравнению с SOAP. Netflix API гораздо ближе, но его использование универсальных типов носителей демонстрирует, что несоблюдение даже одного ограничения может оказать глубокое влияние на выгоды, получаемые от сервиса.
Это может быть не их вина
Я сделал много дампинга на провайдеров услуг, но для того, чтобы танцевать RESTful, нужны двое. Служба может неукоснительно следовать всем ограничениям, и клиент все еще может легко отменить все преимущества.
Если жесткие коды клиента запрашивают доступ к определенным типам ресурсов, это препятствует тому, чтобы сервер изменил эти URL. Любая конструкция URL, основанная на неявном знании того, как сервис структурирует свои URL, является нарушением.
Создание предположений о том, какой тип представления будет возвращен по ссылке, может привести к проблемам. Делая предположения о содержании представления, основываясь на знаниях, которые явно не указаны в заголовках HTTP, определенно создаст связь, которая в будущем вызовет боль.
Должны ли они использовать SOAP?
Лично я так не думаю. Правильное выполнение REST позволяет распределенной системе развиваться в течение длительного времени. Если вы создаете распределенные системы, в которых есть компоненты, которые разрабатываются разными людьми и должны работать в течение многих лет, тогда REST - довольно хороший вариант.
источник
SOAP является объектно-ориентированным , удаленный вызов процедур стека технологии. Он работает путем создания новой абстракции поверх существующего протокола (HTTP).
REST - это документно-ориентированный подход, который просто использует функции существующего протокола (HTTP). «ОТДЫХ» - это просто модное слово - концепция такова: просто используйте Интернет так, как он был спроектирован для работы!
В ответ на правку вопроса:
«Реализация службы REST занимает бесконечно больше времени, чем реализация службы SOAP».
Хм, нет, это не может быть бесконечно дольше. А в тех случаях, когда вы пытаетесь получить документ или файл , на самом деле это происходит намного быстрее . Например, спецификация 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 для любого ресурса в сети? Вы можете прочитать эссе Тима Бернерса-Ли « Холодные URI не меняются» для обоснования, но в основном, пока ресурс может все еще быть полезным в будущем, URI для этого ресурса должен оставаться прежним.
Очевидно, что для временных ресурсов (например, ссылки «сегодняшние деньги» в эссе) в этом нет необходимости, поскольку необходимость ссылаться на ресурс исчезает, если соответствующий ресурс исчезает. Но для более постоянных ресурсов (например, вопросов StackOverflow или фильмов на IMDB) вам нужен URL, который будет работать вечно. Когда вы разрабатываете веб-сервис, вам необходимо решить, смогут ли сами ресурсы пережить ваш сервис, и если это так, то REST, вероятно, является правильным решением.
Кстати, да, я разрабатывал веб-страницы задолго до появления NetFlix или Twitter. И нет, у меня еще не было необходимости или возможности внедрить клиента для служб NetFlix или Twitter. Но даже если с их сервисами ужасно трудно работать, это не значит, что технология, в которой они реализовали свои сервисы, плохая - только то, что эти две реализации плохие.
Короче говоря: REST и SOAP - это всего лишь инструменты . У каждого из них есть свои сильные и слабые стороны. Если единственный инструмент, который у вас есть, это молоток, то каждая проблема выглядит как гвоздь. Так что познакомьтесь с обоими инструментами и научитесь правильно их использовать, а затем выберите правильный инструмент для каждой работы.
источник
Честный вопрос заслуживает честного ответа. Но сначала, почему вы использовали текст этого вопроса в качестве ответа на другой вопрос, если не думали, что он носит риторический характер?
Тем не мение:
« Существуют инструменты для чтения всеми современными языками / средами / платформами в WSDL и вывода прокси-классов и клиентов. Реализация службы REST выполняется вручную путем чтения документации ».
Так же, как производители браузеров читают и перечитывают спецификацию HTML 4.01 вверх и вниз, чтобы попытаться реализовать согласованные возможности просмотра. Задумывались ли вы о том, что браузеры были изобретены задолго до интернет-банкинга и стекового потока, и все же вы можете использовать браузер, чтобы делать именно эти вещи. Это стало возможным благодаря единственной причине, по которой все соглашаются использовать 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 основана на возможностях кеширования, обеспечиваемых всеми другими ограничениями: Примечания диссертации Филдинга : Однако компромисс заключается в том, что унифицированный интерфейс ухудшается эффективность, поскольку информация передается в стандартизированной форме, а не в той, которая специфична для потребностей приложения. Интерфейс REST спроектирован так, чтобы быть эффективным для передачи крупномасштабных гипермедиа-данных, оптимизируя для общего случая Интернета, но в результате получая интерфейс, который не оптимален для других форм архитектурного взаимодействия. Я не думаю, что издержки подсчета байтов в конверте SOAP являются серьезной проблемой.
« Я слышал аргумент, что с REST вы можете просто вставить URL в браузер и посмотреть данные ».
Да, это также неверный аргумент. Это не работает таким образом. Даже если это сработало, большинство узких API-интерфейсов REST используют типы мультимедиа, о которых браузеры даже не подозревают, и все равно они не будут работать.
Но у браузера гораздо больше возможностей для тестирования API, основанного на HTTP, например, утилиты командной строки или расширения браузера, которые позволяют вам контролировать практически любой аспект HTTP-запроса, проверять заголовки ответа и находить ссылки, по которым вы можете перейти. Но даже в этом случае это далеко не так просто, как создание заглушек WSDL и создание трехстрочной программы для вызова функции в любом случае.
« Зачем нам нужен« читаемый »URL для каждого ресурса? Если мы использовали инструмент для реализации сервиса, действительно ли мы заботимся о реальном URL? »
Если вы посмотрите на то, как работает сеть, я почти уверен, что люди в целом рады тому, что URI для страницы википедии выглядит так,
http://en.wikipedia.org/wiki/Stack_overflowа не такhttp://en.wikipedia.org/wiki/?oldid=376349090. Но это на самом деле не важно для отдыха. Важная вещь, которую нужно попытаться сделать правильно, - это выбрать размещение соответствующих данных в URI, которые вряд ли изменятся. Вы можете подумать, что идентификатор базы данных никогда не изменится, но что происходит, когда необходимо объединить два набора данных? Все ваши первичные ключи меняются. Заголовок страницы (Stack_overflow) не изменится.Извините за длинный ответ, но я считаю, что этот вопрос является действительным, и не был рассмотрен ранее здесь, на SO. Я уверен, что Даррел Миллер добавит свой ответ, как только он вернется.
Редактировать: форматирование
источник
У Мартина Фаулера есть пост о модели зрелости Ричардсона, который отлично объясняет разницу между SOAP и REST.
источник
WSDL и другие протоколы уровня документа являются избыточными. Протокол HTTP поддерживает гораздо более богатый набор операций, помимо простого обслуживания документов и отправки форм.
Сторонникам REST неудобно с этой избыточностью.
источник