4 ms·
REST APIs are designed to think in platform centric way. Hateoas are designed to extend the same philosophy. I see The HTML example in the article isn't quite
by the_arun 5y ago
REST APIs are designed to think in platform centric way. Hateoas are designed to extend the same philosophy.
I see The HTML example in the article isn't quite that. I mean the last example which renders content in HTML assumes client wants it for a POST call. What if me as a client using it for GET call? Having said that you as a developer is building a HATEOAS form of content in the user interface. Am I reading this right?
- recursivedoubts 5y agoYou as a client have no say in the matter, beyond asking for particular representations which might be presented to you. A REST-ful (in the true sense of the word) system exposes its API to you through hypermedia: links, forms and so forth. You, the human, may interact with it. But there is nothing outside the API provided by hypermedia, no matter how poorly implemented that hypermedia API might be.
- dragonwriter 5y ago> But there is nothing outside the API provided by hypermedia Hypermedia APIs rely on out-of-band definitions of the semantics of media types and the semantics of operations on media types.
- troutwine 5y ago> But there is nothing outside the API provided by hypermedia, no matter how poorly implemented that hypermedia API might be. I've heard this before about HATEOAS and true-REST but I'm always left wondering about odds and ends. For instance, in the deposit example the client is told that the form accepts "amount" which is of type "number". Does this imply that the unit of amount has to be negotiated between server implementation and client implementation out-of-band? Or, to stick to the same example, how should the client behave if the server responds with a 504? Presumably the client and server would need to agree on the protocol for dealing with failures out-of-band, whether retries are allowed, how and if commits work in the system?
- recursivedoubts 5y agoIdeally the server simply responds to the erroneous state with hypermedia, using hypermedia as the engine of application state. ;) Response codes have always been a bit of a mine field. In htmx, we allow users to hook in and define their own semantics for response codes: https://htmx.org/docs/#modifying_swapping_behavior_with_events https://htmx.org/docs/#modifying_swapping_behavior_with_even...
- troutwine 5y ago> Ideally the server simply responds to the erroneous state with hypermedia, using hypermedia as the engine of application state. ;) I'm really not sure what this means. In the units case how does the server distinguish that the "2" a client sends it is not in millidollars or what not and respond back, without prior and ongoing coordination? Or if the server expects to do a two-phase commit for some POST how would that be communicated to the client without out-of-band communication? Maybe I'm just misunderstanding what "nothing outside the API provided by hypermedia" is supposed to actually encompass.
- ratww 5y agoIn the case of HTML pages, there is ongoing coordination. The server expects the client to have accessed something before that said "please input amount in dollars" or maybe "please input amount in cents". But if there is some new hypermedia format that supports currencies, it can be used instead of a string. What makes it proper hypermedia is that it isn't tightly-coupled with a specific API, it is as "universal" as HTML. "Nothing outside the API provided by hypermedia" means there is no tightly-coupling between server and client other than the protocol and hypermedia format. No schema, no out-of-band-information, no iPhone app... It's just like the browser works: your computer has no special anything for accessing Hacker News, only a fully decoupled client that understands HTTP(S)/HTML (the browser).