Здравствуйте, Miroff, Вы писали:

M>HATEOAS позволяет не размазывать логику между сервером и клиентом. Клиенту не нужно думать, можно ему дергать какой-то ресурс или нет. Прислали ссылку, значит можно. Не прислали -- нельзя.
Это заблуждение. Авторизация проверяется совершенно отдельно. Ещё не хватало в представлении ресурса показывать разный набор ссылок в зависимости от transient штуки вроде Bearer-токена.

M>Вместе с OPTIONS это такой подход позволяет полностью перенести авторизацию с клиента на сервер.
Размещение авторизации ортогонально HATEOAS. Естественно, она полностью выполняется на сервере. Если вы хотите прятать кнопки на клиенте на основе правил авторизации, то это в большинстве случаев контрпродуктивная идея.

M>Или, например, пейджинг: клиенту не нужно вычислять сколько страниц всего, какая предыдущая, какая следующая и т.п. Вместо этого ему сразу приходит список страниц, которые можно дернуть.
Да, пейджинг — это один из немногих случаев корректного и полезного применения ссылок. Но вообще, его изготовить правильно — очень сложно. Сильно сложнее, чем кажется на первые три взгляда. В частности, "список страниц, которые можно дёрнуть" — плохая идея, которая ломается в большом количестве сценариев.

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

M>HATEOAS это про чтение, что ты собрался использовать при чтении.
Нет конечно. HATEOAS — это про идентификацию ресурсов. REST сам по себе (даже без HATEOAS) — как раз про то, что все действия выполняются через управление представлением состояния.
В частности, приделывание к платёжке ссылки refund с методом POST — это RMM не L3, а L1. Потому, что нормальный способ — это PUT либо PATCH, которые прямым либо косвенным образом меняют состояние платежа на refunded.

M>Можно ли поменять owner? Надо пробовать, может да, может нет, может в каких-то случаях да, а в остальных нет. Даже OpenAPI не позволяет описать настолько сложные контракты.
Конечно позволяет. Вот у вас есть объект, у него есть представление. Всё, можно делать PUT этого представления. Если что-то запрещено бизнес-правилами — приедет 409. Если правами доступа — 403.

S>>- что делает глагол refund, и какие у него будут параметры, и где их брать
M>Это же ресурс, делаешь GET, смотришь, меняешь, делаешь PUT.
Нет конечно. Это не ресурс, это адрес для POST запроса.

M>Правильно делать GET перед PUT, потому что ссылки могут измениться, и вообще конкурентные обновления. Если разработчики не умеют пользоваться REST API это их проблема. Можно тупо менять ссылки при каждом запросе, чтобы даже желания сохранять их куда либо не возникало.
Ну, у нас же нет REST-полиции. Никто вас не арестует за такую реализацию (и за любую другую). Но на практике людям больше нравятся сервисы, которые не требуют от них делать лишние запросы, увеличивая трафик и латентность.
Особенно когда гипотетическая нужда переноса URL-ов для parent payment не наступает никогда.

M>Я тебя умоляю, мы видео в 4К по сети гоняем и GUID вместо id используем. Несколько ссылок погоды не сделают.
Сделают. Стоимость эксплуатации складывается из мелочей. Два-три десятка таких идиотских решений — и вот уже ваш стейкхолдер вместо одного виртуального сервера оплачивает ферму из восьми выделенных.