Mobile dev here. If you are talking about native mobile then I'v played around with using HATEOAS with native code in the past (around ~2013).
It works fine but is obviously not as flexible as on the web. It also does require that each linkable screen be developed in a strict black box fashion.
It was a fun exercise to try out, but not sure what the value of using it in production would be.
I've found that HATEOAS is actually quite good for CRUD. You "link" to "lists" and items, and the information in the responses is enough to assemble pages, forms, other lists.
This way you only gotta build the "abstraction" in the app itself, the real structure of each page is entirely in the APIs.
Thing is, this saves money at the start, but people obviously want more customisation than is appropriate here. And as more and more pages become bespoke, hypermedia stop making sense :(
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.
MrDresden|2 years ago
It works fine but is obviously not as flexible as on the web. It also does require that each linkable screen be developed in a strict black box fashion.
It was a fun exercise to try out, but not sure what the value of using it in production would be.
whstl|2 years ago
This way you only gotta build the "abstraction" in the app itself, the real structure of each page is entirely in the APIs.
Thing is, this saves money at the start, but people obviously want more customisation than is appropriate here. And as more and more pages become bespoke, hypermedia stop making sense :(
AtlasBarfed|2 years ago
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.
EspressoGPT|2 years ago
nymanjon|2 years ago