AS
И так зачем?
Size: a a a
2017 May 29
GK
когда у тебя развесистый JSON, справочники с десятками полей, HATEOAS очень удобен
GK
особенно когда клиент - SPA
GK
можно сделать отличное API, если клиенты участвуют в дизайне API
AS
Зачем передавать url целиком, если можно передавать идентификатор?
GK
идентификатор коллекции?
AS
ну стоп
GK
uri - это и есть идентификатор
AS
В общем на мой взгляд HATEOAS некоторый вынос логики клиента на сервер. Это может упростить разработку клиента, но явно влияет на архитектуру клиента
AS
А должно быть разделение ответственности
AS
Если у меня есть еще и мобильный клиент, то зачем мне все эти uri?
GK
может в этом случае тебе нужен BFF?
GK
зависит от ситуации, как всегда
AS
BFF это само собой
AS
Но не для каждого frontenda свой backend
AS
19 слайд очень хороший. Прихожу к мысли, что это и есть архитектура
DM
Имхо, HATEOAS нужен, если клиентский интерфейс может _динамически_ по нему строиться. В остальных случаях это получается избыточно, но не дает всех выгод
GK
Denis Migulin
Имхо, HATEOAS нужен, если клиентский интерфейс может _динамически_ по нему строиться. В остальных случаях это получается избыточно, но не дает всех выгод
Да, именно про этот кейс я и говорю. Мы имплементировали HATEOAS в MDM решении, где на основе метаданных генеруется UI для очень развесистых справочников
AS
Собственно мой вопрос был является ли HATEOAS высшим уровнем maturity. Скорее некоторое расширение при определенном уровне развития.