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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следует отметить, что Рой не был первоначальным изобретателем большинства принципов 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, которым не нужно пересекать организационные границы и системы, которые имеют относительно короткий период амортизации.

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

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

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

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

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

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

ОТДЫХ в AEM

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