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?
You 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.
> 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?
> 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.
In 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).
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?