Является ли REST и HATEOAS хорошей архитектурой для веб-сервисов?

15

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

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

Меня беспокоит то, что HATEOAS имеет смысл для гипермедиа, потому что существует мало известных типов контента (HTML, изображения, видео и т. Д.), И клиент знает, как их использовать. Но для API типы контента очень специфичны и могут потребляться осмысленно только клиентом, если клиент специально запрограммирован на их использование. Возврат URL-адреса клиенту сам по себе не позволяет клиенту использовать указанный ресурс.

JacquesB
источник
2
Поскольку сеть основана на использовании HTTP, а REST - это HTTP, я думаю, что это отличная вещь для использования.
Роб
1
@Rob: ОТДЫХ больше, чем HTTP. Например, SOAP и XML-RPC также использует HTTP, но не соответствует REST.
JacquesB
Ни то, ни другое не основано на архитектуре REST. Отсюда и разница.
Роб
4
Это действительно сложный вопрос. Потому что в конечном итоге это так же хорошо или плохо, как любая предыдущая или текущая технология. Это зависит от вашей задачи. Для некоторых задач это работает. Для других мы собираемся в Graphql или Falcor / JSONGraph. Или даже бинарный (gRPC) снова в моде. С моей точки зрения, обещание HATEOAS и «умных клиентов» не сработало. Накладные расходы убили это.
Томас Джанк
Это зависит от многих вещей. Не все из них технические проблемы. Контекст, связанный с имплантацией и исполнением имеет значение.
Laiv

Ответы:

15

AFAIK Fielding не утверждал, что REST - это хорошо, он просто описывал фактическую архитектуру сети.

Я думаю, это немного недооценивает это. В конце концов, REST - это перечисление архитектурного стиля, который Филдинг использовал в качестве главного архитектора спецификации HTTP / 1.1 .

Но есть ли причина думать, что REST является желательной архитектурой для этого домена? Есть ли доказательства того, что HATEOAS - это выгодный принцип проектирования межмашинных коммуникаций?

"По-разному". HATEOAS является частью ограничения интерфейса REST.

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

Итак, давайте немного подумаем о том, что это значит. Когда у меня возникают проблемы с моим беспроводным маршрутизатором, я могу общаться с ним с помощью того же браузера, который я использую для отправки ответов на stackexchange. В частности, не имеет значения, какой браузер я использую или какой браузер на несколько обновлений отстает (или опережает) от того, что ожидает маршрутизатор. Неважно, что инженерная организация, написавшая браузер, полностью независима от организации, создавшей интерфейс маршрутизатора.

Это просто работает .

Это, конечно, не универсально. Филдинг в 2008 году писал:

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

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

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

schema.org - это часть усилий по созданию машиночитаемого словаря; Агенты машины используют клиента для поиска семантических подсказок и применяют свое собственное понимание значения, чтобы выбрать правильные действия.

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

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

VoiceOfUnreason
источник
Интересный ответ. Кажется, особенно на основе этой цитаты: « Интерфейс REST разработан, чтобы быть эффективным для крупномасштабной передачи гипермедиа данных, оптимизируя для общего случая Интернета, но в результате получается интерфейс, который не оптимален для других форм архитектурного взаимодействия. «Филдинг не считает REST-архитектуру оптимальной для сервисных API. (Конечно, REST все еще лучше, чем SOAP, даже если он не оптимален!)
JacquesB
Трудно сказать, что Филдинг посчитает оптимальным :-). Я полагаю, что некоторые API-интерфейсы должны включать в себя передачу гипермедиа данных.
Laiv
6

Нет, «полный ОТДЫХ» не так уж и велик.

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

Но вы должны понять, почему REST так популярен. До его принятия существовали различные сумасшедшие сложные протоколы, такие как ebXML и SOAP, включающие подтверждения, тайм-ауты, идентификаторы разговоров и состояние.

Работать с этими вещами и объяснять их потребителям API было непросто. "почему бы мне просто не сделать GET с нужным мне идентификатором в строке запроса, а вы отправили мне данные?" был очевидный и общий вопрос.

Тогда второй проблемой был XML, javascript не понимал этого, схемы были проблемой в заднице, и вы в конечном итоге получили огромные текстовые файлы, состоящие в основном из <MyLongObjectName>. Поэтому люди начали использовать JSON.

Теперь у REST есть что-то вроде культа, но поскольку правила настолько расплывчаты, это не мешает вам запустить полезный API, который достаточно прост, чтобы потребители «просто получили» и использовали его без 6 месяцев при посадке. процесс.

Ewan
источник
Одна из часто заявляемых претензий Филдинга - отсутствие понимания людьми REST и правильной реализации. Это не провал REST. Сбой Javascript с XML не является проблемой с REST. И Javascript, и XML не имеют ничего общего с REST. То, что Филдинг сделал себя доступным в Интернете, написал статьи за пределами своей диссертации, указал на примеры правильного использования REST, и у людей, похоже, нет проблем с пониманием его написания и реализации HTTP, кажется, показывает, что не должно быть много проблем с пониманием и правильно внедряя REST.
Роб
XML не имеет никакого отношения к тому, является ли REST хорошей архитектурой API или нет, в стандарте нет ничего, что требовало бы XML в качестве формата ресурса. JSON, HTML, простой текст - все это допустимые ресурсы.
Пол
2
Я думаю, что когда мы говорим о REST, мы должны понимать, что такое стандарт И что люди реализуют в реальности, а затем ВЫЗВАТЬ «REST»
Ewan
2

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

Еще до того, как Рой Филдинг написал свою диссертацию о REST , HTTP уже был разработан на основе принципов, которые впоследствии стали называться REST. В заключение своей диссертации он написал:

В начале наших усилий в рамках Internet Engineering Taskforce определить существующий протокол передачи гипертекста (HTTP / 1.0) [19] и разработать расширения для новых стандартов HTTP / 1.1 [42] и унифицированных идентификаторов ресурсов (URI) [21]. ], Я осознал необходимость модели работы Всемирной паутины. Эта идеализированная модель взаимодействия внутри общего веб-приложения, называемая архитектурным стилем передачи представительного состояния (REST), стала основой для современной веб-архитектуры, предоставляя руководящие принципы, по которым могут быть выявлены недостатки в существующей архитектуре, и расширения проверено до развертывания .

REST и HATEOS хорошо подходят для задачи, для которой они были разработаны:

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

Однако следует отметить, что Web и REST не обязательно подходят для любых проблем:

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

Итак, если ваш вопрос «Является ли REST и HATEOAS хорошей архитектурой для веб-сервисов?» тогда ответом будет просто «да, это хорошая архитектура для веб-сервисов». Проблема на самом деле заключается в том, должны ли все проблемы, которые люди пытались решить, переоборудовав их в веб-ограничения, действительно быть веб-сервисами.

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

Но есть ли причина думать, что REST является желательной архитектурой для этого домена? Более конкретно, есть ли доказательства того, что HATEOAS является выгодным принципом проектирования для межмашинной связи?

Свидетельством тому является успех Сети в решении проблем многих людей. REST - это гибридная архитектура, которая сочетает в себе конструкции многих предыдущих архитектурных стилей. Многие проблемные домены не имеют всех требований Интернета и не должны подчиняться всем ограничениям REST, чтобы работать хорошо. Вот почему существует много успешных архитектур, которые отлично работают, просто применяя некоторые части REST, но не другие. HATEOAS и Uniform Interface, например, являются принципами, которые часто пропускаются API, которым не нужно пересекать организационные границы и системы, которые имеют относительно короткий период амортизации.

Ли Райан
источник
2

В презентации Филдинга на Adobe Experience Manager:

ОТДЫХ - это НЕ архитектура!

Отдых - это архитектурный стиль, который представляет собой абстракцию другой архитектуры, существующей в Интернете.

REST - это совокупность проектных ограничений для создания архитектурных свойств.

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

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

ОТДЫХ в AEM

imel96
источник
0

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

Ричард
источник
1
Почему JSON уступает XML?
Malky.Kid
@ Malky.Kid: Конечно, всегда можно найти способ представить любой XML-документ как JSON, поэтому JSON не уступает тому, что вы можете с ним выразить. Но XML, с одной стороны, предлагает больше синтаксических возможностей для выражения метаданных « из коробки» (схема, информация о типе, комментарии, пространства имен, инструкции по обработке, даже используемая кодировка символов) без необходимости изобретать и выбирать схему данных. делать эти вещи для них (как это происходит с JSON), поэтому в этом смысле я думаю, что было бы справедливо сказать, что он предлагает более широкие возможности, чем JSON.
stakx