Является ли REST только адекватным для приложений с взаимодействием человека и компьютера?

Question

Я довольно новичок в создании приложений с использованием архитектуры RESTful. На самом деле, все, что я сделал до сих пор, относится к Level 2 REST Леонардом Ричардсоном и что я знаю, что Филдинг будет happily categorize как не-RESTful.

Я потратил часы, пытаясь понять ХАТЕОАС и как достичь уровня 4. И теперь я вижу это более четко. Я концептуализую приложение как серию переходов состояний, и ресурсы будут динамически предоставлять ссылки с информацией о том, как переходить из одного состояния в другое.

Но все, что связано с HATEOAS, похоже, связано с взаимодействием человека и компьютера. Я имею в виду, что даже когда ресурсы предоставляют ссылки, которые позволяют пользователю приложения переходить в следующее состояние, в конечном счете пользователь, который управляет приложением из одного состояния в другое, вызывая использование предоставленных ссылок.

Но как должны работать вещи, когда мы имеем дело с взаимодействием компьютера с компьютером? В конце концов, когда дело доходит до служебной ориентации, идея композиции сервиса является ключевой, и мы не можем наивно предположить, что клиент всегда будет человеком? Многие сервисы предназначены для использования пользователями, не являющимися пользователями, и некоторые взаимодействия/оркестровки могут быть довольно сложными, тип вещей, которые обычно моделируются с помощью таких вещей, как BPM или BPEL.

Является ли REST и особенно HATEOAS применимым только в приложениях, которые подразумевают вмешательство человека, и если не так, как это должно работать иначе?

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

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

Answer 1

Ну, ваше клиентское приложение может проанализировать ответ, чтобы получить возможные действия. В этом случае фактические URL-адреса получаются не от знания API, а при вызове исходного метода (обычно GET). Все без человека.

Answer 2

Звучит так же, как если бы вы сравнивали SOA с REST/Hypermedia и не видели, что SOA - это стратегия для разработки сложной системы, созданной из других систем, тогда как REST/Hypermedia - это стиль архитектуры программного обеспечения, связка ограничений на взаимодействие клиент-сервер. Клиент, однако, может быть как сервером, так и человеком, это не имеет значения.

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