> For true MVC we need a central long living controller не контроллер а view. Контроллер stateless и его цикл жизни вообще никого не интересует

Почему?

потому что он stateless)

в целом и view может быть stateless а модель просто сообщаент ивентами вьюхе "обновиться"

А restful почему не имеет практического смысла?

ну то есть вьюха отображает стэйт приложения для пользователя, пользователь кликает на какой-то контрол и событие приходит в контроллер. Контроллер на это событие просить модель что-то сделать. Модель что-то делает и кидает событие "я обновилсо" и вьюха по этому событию себя перерисовывает. Данные идут строго в одном направлении. На бэкэнде это никому особо не нужно

А restful почему не имеет практического смысла?

потому что подавляющее большинство не знают что это такое

а если большинство не знают, то употреблять этот термин нет смысла

играл же в испорченный телефон

ну мол пример. Я тебе говорю "у меня restful API" а ты себе "так, то есть у него есть CRUD-like HTTP API"

или например "GraphQL круче REST"

большинство думают "круто! нафиг HTTP API!" а я думаю "Воу воу, но... graphql в целом похож на что-то restful"

И что же такое Restful API?)

Не знаю что такое REST.

Representational State Transfer. Ключевое слово - state transfer.

не термин его

а основопологающая

ну то есть у тебя есть граф объектов и связи между ними. Это все - ресурсы. У них есть идентификаторы - URI. Ты можешь что-то делать со всем этим (GET/POST/PUT/DELETE) и за счет этого происходит переход системы из одного стэйта в другой

в целом REST это набор ограничений которые дают тебе определенные характеристики архитектуры

Да я то в курсе, что это, думал может что-то новое узнаю)

в википедии всё есть

ну тип по сути правильный REST нельзя сделать без HATEOAS

а HATEOAS делают мало кто

вот когда у тебя ресурс сам тебе говорит какие релейшены у него могут быть

тогда можно делать крутые штуки

это все из разряда over engineering

это все из разряда over engineering

и да и нет. Могу привести простой пример

у тебя есть API

например... что-то типа бложика

простая шляпа да?

есть ресурс - "статья". и ее можно редактировать например

идет время и помимо "автора статьи" и "администратора" (такие проверки на клиенте делать удобно) появляются штуки вроде "а еще статью могут редактировать главный редактор блога и редакторы разделов"

и тут уже сложности начинаются

скорее всего закончится это какими-то флагами в json аля editable: false

а можно добавить линку

{"rel": "article.edit", "href": "https://api.com/articles/123"}

для этих дел

и клиент будет знать что если есть такой релейшен - значит надо показывать кнопку edit

есть State Machine

есть State Machine

HATEOAS и есть способ задания state machine

и ACL

и ACL

не понял

ну то есть с какой стороны у тебя ACL будет?

на клиенте продублируешь?

или на сервере будешь говорить ресурсам в какой стэйт они могут перейти? (ну мол твой автомат)

а в чем проблема стеделать HATEOAS на основе ACL, StateMachine?

Да я то в курсе, что это, думал может что-то новое узнаю)

))))

и выдавать ресурсы

какие нужны

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

а в чем проблема стеделать HATEOAS на основе ACL, StateMachine?

я немного не понимаю, я же это и предлагаю

поэтому я и написал, что мы о том же

об одном и том же

ну проблема в том что помимо ACL есть еще масса вещей которые часто дублируются на клиенте

ну и опять же большинство просто не делают HATEOAS

потому дублирование логики на клиент и вылазит

ну без HATEOAS нереально сделать нормальный websocket даже

потому что логика будет дублироваться

на клиенте, на вебсокете

на бэкенде

ну без HATEOAS нереально сделать нормальный websocket даже

я опять же не уверен что правильно тебя понял

тип у тебя когда ты шлешь ивент в нем есть "следующий стэйт"?

ну тип что-то типа тех же релейшенов только вместо URI используется что-то другое?

или ты просто говоришь про сферические конечные автоматы в вакууме

я имею ввиду конктертную реализацию HATEOAS

и как он формирует все связи

и посредством чего

ERROR: S client not available

ладно не важно, мы об одном и том же, я это понял

долго все расписывать

было бы время

)

я имею ввиду конктертную реализацию HATEOAS

в контексте websockets давай

конкретную)

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

и что бы не дублировать ничего

можно се сделать посредством вот этих вот действий

так это не про HATEOAS

ну мол HATEOAS это про гипермедиа

а я что-то как-то не видел websockets передающие гипертекст (с релейшенами)

а зачем передевать

так блин

ну допустим если сокеты

мы таки про разные штуки походу говорим

socket.io

ну

не имеющие доступа к сервисам

только API

хотя не

можно но костыль

но не везде нужен HATEOAS

но не везде нужен HATEOAS

что для тебя HATEOAS

ну мол это вполне конкретная штука (в отличии от REST)

https://spring.io/understanding/HATEOAS

Hypermedia как минимум в названии должен намекать

отсюда понимал еще когда Spring учил

ну, а теперь причем тут socketio?

я ж ответил

это костыль

ну то есть да, мы можем сделать ивенты кусочками стэйта с транзишенами описанными в виде релейшенов