I have only ever seen HATEOAS as an abstract concept, but never actually seen a real UI where I think "wow that is actually an improvement in user interaction".
REST was a welcome simplification of the SOAP monstrosities, but it comes with a lot of dogma. REST aligns natural user concepts with data with the service architecture, so I see its purpose fundamentally.
HATEOAS seemed like a product of people wanting even more dogma / pretentious drivel in architecture meetings without really concentrating on if the user experience is improved by the model.
Does anyone have a HATEOAS UI example that highlights why you would use it as some founding principle? I mean fundamentally each page has links to "what to do next", and my impression of HATEOAS is a blinged up way of trying to bring some sort of similar state model to REST service calls.
Comments
I have only ever seen HATEOAS as an abstract concept, but never actually seen a real UI where I think "wow that is actually an improvement in user interaction".
REST was a welcome simplification of the SOAP monstrosities, but it comes with a lot of dogma. REST aligns natural user concepts with data with the service architecture, so I see its purpose fundamentally.
HATEOAS seemed like a product of people wanting even more dogma / pretentious drivel in architecture meetings without really concentrating on if the user experience is improved by the model.
Does anyone have a HATEOAS UI example that highlights why you would use it as some founding principle? I mean fundamentally each page has links to "what to do next", and my impression of HATEOAS is a blinged up way of trying to bring some sort of similar state model to REST service calls.