Должен ли веб-сервис в стиле Netflix или Twitter использовать REST или SOAP? [закрыто]
Исправлено для меня:
curl --remote-name --time-cond cacert.pem \ https://curl.haxx.se/ca/cacert.pem
4 ответа
Канарейка в угольной шахте.
Я ждал такого вопроса почти год. Этот день неизбежно наступил, и я уверен, что в ближайшие месяцы мы увидим еще много подобных вопросов.
Предупреждающие знаки
Вы абсолютно правы, создание клиентов 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, почему бы просто не сосредоточить наши усилия на одном и сделать это хорошо?
Как все пошло так не так
I Расскажу, что пошло не так. Мы, как разработчики, позволяем отделам маркетинга воспользоваться нашей основной слабостью. Наши вечные поиски серебряной пули закрыли нам глаза на реальность того, чем на самом деле является 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 определенно стал мейнстримом. Практически каждый крупный веб-ресурс, имеющий API, поддерживает REST. Twitter и Netflix - два очень известных. Страшно то, что я могу думать только об одном общедоступном API, который является самоописательным, и есть несколько, которые действительно реализуют ограничение гипермедиа.Конечно, некоторые сайты, такие как StackOverflow и Gowalla, поддерживают ссылки в своих ответах, но в их ссылках есть огромные дыры. У StackOverflow API нет корневой страницы.Представьте себе, насколько успешным был бы веб-сайт, если бы для него не было домашней страницы!
Боюсь, вы были введены в заблуждение.
Если вы зашли так далеко, краткий ответ на ваш вопрос заключается в том, что API (Netflix и Twitter) не соответствуют всем ограничениям, и поэтому вы не получите преимущества, которые должны принести REST apis.
Создание клиентов REST занимает больше времени, чем клиентов SOAP, но они не привязаны к одной конкретной службе, поэтому вы должны иметь возможность повторно использовать их в разных службах. Возьмем классический пример веб-браузера. К скольким службам может получить доступ веб-браузер? А как насчет читателя ленты? Теперь, к скольким различным сервисам может получить доступ средний клиент Twitter? Да только один.
REST-клиенты не должны быть созданы для взаимодействия с одной службой, они должны быть созданы для обработки определенных типов мультимедиа, которые могут обслуживаться любой службой. Возникает очевидный вопрос: как создать REST-клиент для службы, доставляющей application / json или application / xml. Ну, ты не можешь. Это потому, что эти форматы совершенно бесполезны для клиента REST. Вы сами сказали
, что вы должны делать «догадки» относительно того, что вернется через трубу, как нет реальной схемы или ссылки document
Вы абсолютно правы в отношении таких сервисов, как Twitter. Однако самоописательное ограничение в REST гласит, что заголовок типа содержимого HTTP должен точно описывать содержимое, которое передается по сети. Доставка application / json и application / xml ничего не говорит вам о содержимом.
Когда дело доходит до оценки производительности систем на основе REST, необходимо смотреть на более широкую картину. Говорить о байтах конверта - все равно что говорить о раскручивании цикла при сравнении быстрой сортировки с сортировкой оболочки. Есть сценарии, в которых SOAP может работать лучше, а есть сценарии, где REST может работать лучше. Контекст - это все.
REST в значительной степени выигрывает в производительности за счет гибкости в отношении поддерживаемых типов носителей и наличия развитой поддержки кэширования. Чтобы кеширование работало хорошо, необходимо соблюдать почти все ограничения.
Ваше последнее замечание о читаемых URL-адресах, безусловно, является самым ироничным. Если вы действительно соблюдаете ограничение гипермедиа, тогда каждый URL-адрес может быть GUID, и разработчик клиента ничего не потеряет в удобочитаемости.
Тот факт, что URI должны быть непрозрачными для клиента, является одним из важнейших моментов при разработке систем REST. Читаемые URL-адреса удобны для разработчика сервера, а хорошо структурированные URL-адреса облегчают серверной инфраструктуре отправку запросов, но это детали реализации, которые не должны влиять на разработчиков, использующих API.
Twitter API даже близко не похож на RESTful, и поэтому вы не видите каких-либо преимуществ от его использования по протоколу SOAP. Netflix API намного ближе, но использование универсальных типов мультимедиа демонстрирует, что несоблюдение даже одного ограничения может иметь огромное влияние на преимущества, получаемые от сервиса.
Возможно, это не их вина.
Я много раз перебил поставщиков услуг, но для того, чтобы танцевать ОТДЫХ, нужны двое. Служба может неукоснительно следовать всем ограничениям, и клиент все равно может легко отменить все преимущества.
Если клиент жестко кодирует URL-адреса для доступа к определенным типам ресурсов, это не позволяет серверу изменять эти URL-адреса. Любое построение URL-адресов, основанное на неявном знании того, как служба структурирует свои URL-адреса, является нарушением.
Предположения о том, какой тип представления будет возвращен по ссылке, может привести к проблемам. Предположения о содержании представления, основанные на знаниях, которые явно не указаны в заголовках HTTP, определенно создадут связь, которая вызовет боль в будущем.
Стоило ли им использовать протокол SOAP?
Лично я так не думаю. Правильно сделанный REST позволяет распределенной системе развиваться в долгосрочной перспективе. Если вы создаете распределенные системы, компоненты которых разрабатываются разными людьми и должны прослужить много лет, тогда REST - довольно хороший вариант.
WSDL и другие протоколы уровня документов являются избыточными. Протокол HTTP поддерживает гораздо более широкий набор операций, помимо простого обслуживания документов и отправки форм.
Сторонникам 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 Envelope. В наши дни, действительно ли нам нужно беспокоиться о нескольких байтах?»
Да. Не во всех обстоятельствах, но есть сайты с большим объемом трафика, где это имеет значение. Достаточно ли разницы, чтобы перевесить семантические различия использования SOAP вместо REST? Я сомневаюсь. Если вы используете протокол удаленного взаимодействия с объектами и количество байтов имеет значение, SOAP, вероятно, в любом случае вам не подходит - возможно, вам следует использовать CORBA или DCOM.
«Я слышал аргумент, что с помощью REST вы можете просто вставить URL-адрес в браузер и просмотреть данные».
Да, и это большой аргумент в пользу REST , если он имеет смысл для просмотра данных в браузере .Например, с данными изображения это простой способ отладить службу - просто вставьте URL-адрес в адресную строку браузера и посмотрите, как выглядит изображение. Или, если возвращаемые данные представлены в формате XML и у вас есть указанная таблица стилей XML, которая преобразуется в читаемый HTML-код в браузере, тогда вы получаете преимущества семантической разметки и простой визуализации - все в одном пакете. Но вы правы, это преимущество по большей части испаряется при работе с более сложными схемами аутентификации. Если вы не можете закодировать всю свою аутентификационную информацию в каждом HTTP-запросе , то я бы сказал, что он вообще не считается REST.
«Зачем нам нужен« читаемый »URL-адрес для каждого ресурса? Если бы мы использовали инструмент для реализации службы, действительно ли нам важен фактический URL-адрес?»
Ну, это зависит от обстоятельств. Зачем нам нужны читаемые URL-адреса для любых ресурсов в Интернете? Вы можете прочитать эссе Тима Бернерса-Ли Cool URIs Don't Change для обоснования, но в основном, пока ресурс может быть полезен в будущем, URI для этого ресурса должен оставаться прежним.
Очевидно, что для временных ресурсов (таких как ссылка «Сегодняшние деньги» в эссе) в этом нет необходимости, поскольку необходимость ссылаться на ресурс исчезает, если соответствующий ресурс исчезает. Но для более постоянных ресурсов (например, вопросов о StackOverflow или фильмов на IMDB) вам нужен URL-адрес, который будет работать вечно. Когда вы разрабатываете веб-службу, вам нужно решить, смогут ли сами ресурсы пережить вашу службу, и если да, то REST, вероятно, будет правильным путем.
Для справки, да, я занимался разработкой веб-страниц задолго до того, как появились NetFlix или Twitter. И нет, у меня еще не было ни потребности, ни возможности внедрить клиента ни в NetFlix, ни в сервисы Twitter. Но даже если с их услугами ужасно сложно работать,это не означает, что технология, на которой они реализовали свои сервисы, плоха - просто эти две реализации плохи.
Короче говоря: REST и SOAP просто инструменты . У каждого из них есть сильные и слабые стороны. Если единственный инструмент, который у вас есть, - это молоток, то каждая проблема выглядит как гвоздь. Итак, познакомьтесь с обоими инструментами и научитесь правильно ими пользоваться, а затем выберите подходящий инструмент для каждой работы.
Честный вопрос заслуживает честного ответа.Но сначала, почему вы использовали текст этого вопроса как ответ на другой вопрос , если вы не считали его риторическим по своей природе?
В любом случае:
« Инструменты существуют для все современные языки / фреймворки / платформы для чтения в WSDL и вывода прокси-классов и клиентов. Реализация службы REST выполняется вручную путем чтения документации. "
Точно так же, как производители браузеров прочитали и перечитали HTML 4.01 вверх и вниз, чтобы попытаться реализовать согласованный опыт просмотра. Задумывались ли вы о том, что браузеры были изобретены задолго до интернет-банкинга и stackoverflow, и тем не менее вы можете использовать браузер для этих целей. Это стало возможным по той единственной причине, что все соглашаются использовать HTML (и связанные с ним форматы, такие как CSS, JS, JPEG и т. Д.).
Ведение блогов на самом деле не так уж и ново, и кто-то придумал AtomPub, который позволяет любому программному обеспечению для ведения блогов получать доступ и обновлять сообщения в блоге, так же, как любой веб-браузер может получить доступ к любой веб-странице. Это довольно удобно и работает из-за ограничений RESTful, налагаемых протоколом.
Но для Twitter и Netflix не существует универсального соглашения о том, что «все существующие микроблоги должны использовать мультимедийный тип application / tweet», главным образом потому, что микроблоги появились недавно. Возможно, через несколько лет несколько сервисов микроблогов остановятся на одном API, так что Twitter, Facebook, Identica и смогут взаимодействовать друг с другом. Ни один из их существующих API-интерфейсов и близко не подходит к RESTful, как бы они ни заявляли, поэтому я не ожидаю, что это произойдет в ближайшее время.
« Кроме того, при реализации этих двух сервисов вы должны делать« предположения »относительно того, что вернется через конвейер, поскольку нет реальной схемы или справочного документа. «
You ' попал в самую точку. REST - это все о распределении и гипермедиа, и это в значительной степени подводит итог. Браузер смотрит на то, что он получает от запроса, и показывает это пользователю. HTML-страница обычно порождает намного больше запросов GET, например CSS, скрипты и изображения. Изображение обычно только выводится на экран, выполняется JavaScript и т. Д. Каждый раз браузер делает то, что он делает, потому что он нашел ссылку в теге