Является ли RESTful (HATEOAS) практичным для специализированных клиентов?

Question

Есть ли доказательство клиента концепции (то есть веб-приложения), которое представляет собой приложение реального мира, реализованное с использованием и использованием принципов RESTful? Все, что я могу найти, это браузеры API, но разработка приложения реального мира (т. Е. Социальной сети или веб-сайта электронной коммерции) совершенно иная.

Я прочитал работу Роя и связанные с ней документы, но я все еще не могу вздохнуть, как максимально использовать Restful в развитии клиента. Я всегда сохраняю состояние на клиенте или специализируюсь на рендеринге медиа/типа. Например, один и тот же ресурс (то есть ресурс профиля) визуализируется по-разному на основе контекста (то есть на главной странице, на странице продукта или на странице специализированного профиля), так что прощальный медиа-тип -> код по запросу.

Я действительно не вижу никакого преимущества (в том, как я работаю) HATEOAS над API с хорошо определенным/автогенерированным IDL (то есть гипер-схемой json).

Мое заключение заключается в том, что только общие клиенты (например, google) могут воспользоваться HATEOS, а не реальными/специализированными приложениями. Специализированная клиентская разработка, похоже, не приносит никакой пользы, если ваш API поддерживает HATEOS, а не описывается IDL.

Answer 1

Хотя это правда, что HATEOAS дает вам гибкость URI и человеческое обнаружение потоков, реальная выгода использует его как кодирование ресурса состояние.

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

Возможность использовать возможный переход состояния предлагается клиентам REST посредством операций против URI ресурсов - с помощью гиперссылки HATEAOS вы можете определить переходы известным именем ссылки ссылки, а затем включить или исключить ссылки rel, в зависимости от которые переходы разрешены текущим состоянием.

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

Другая причина включения или исключения конкретной ссылки rel может быть связана с разрешениями доступа, предлагаемыми текущему пользователю. Просто исключите их, если текущему пользователю не разрешено выполнять переход.

Если вы не используете динамическое включение или исключение ссылок rel на основе состояния ресурса и/или состояния авторизованного пользователя, тогда ваш анализ плюсов минус довольно хорош, потому что вы не используете их по реальной причине, они были включены. В конце концов, S в REST означает состояние! :)

Answer 2

HATEOS - это философия дизайна/стиль/вкус, и это во многом вопрос вкуса или компромисса между полномасштабным кодом gen и письменным API.

Ключевым отличительным аспектом HATEOS является способ создания ссылок на другие ресурсы API (а именно по полному URL-адресу). Это устраняет большую нагрузку на документацию, которую вы могли бы столкнуться, если ответ API включает только идентификатор (а не полный URL-адрес ресурса).

Однако при использовании HATEOS с JSON вместо XML вы потеряете часть другого контекста (например, я должен PUT или GET или POST к этой конечной точке?), И поэтому вы должны дополнить это с каким-то другим видом метаданных, если вы хотите создать клиента или документацию для людей.

По моему опыту API HATEOS намного проще для людей потреблять с помощью простых клиентов REST (например, cURL) по сравнению с WSDL или IDL, который предполагает, что клиент использует сгенерированный код и никогда не коснется API напрямую.

Компромиссы

Так почему бы вы выбрали HATEOS против WSDL или какого-либо другого генерируемого варианта?

Основополагающее предположение для API (что не всегда верно) заключается в том, что у них будет много вкусов клиентов/потребителей, возможно, реализованных на разных языках. Это означает, что со временем письма и обновления клиентов работают больше, чем написание службы.

Если вы или ваша компания собираетесь поддерживать клиентов API самостоятельно, тогда возникает ценовая компромисс между генерирующим кодом для всех клиентов (WSDL, SWIG и т. Д.) Или наймом разработчика для конкретного языка для его поддержки.

Скорее всего, сгенерированный клиент API не будет следовать идиоматическому стилю для любого заданного языка, а код, как правило, уродлив. Если это имеет значение для вас, вам, вероятно, понадобится человек, чтобы написать код клиента. Если вас это не волнует, вы можете прекратить читать о HATEOS и вместо этого использовать WSDL или аналогичный подход.

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

Пример

Для примера HATEOS-подобный API взглянуть на GitHub API. С помощью клиента REST довольно легко просматривать, и как только вы узнаете, как выполнить проверку подлинности, вы можете найти большинство вещей, которые вы хотите, указав ссылки на URL-адреса данных. Вам все равно придется ссылаться на документацию для конкретных деталей и расширенных прецедентов (например, данные POSTing), но очень просто написать простой клиент для GitHub без привлечения клиентской библиотеки GitHub или чтения документов в конец.