I still do not understand how the client knows what POST data is when creating the resource. Most textbooks / articles omit this in their examples, the client always seems to know a priori what to publish (i.e. use out-of-band information). As in the this example , the consumer knows that he must place an order, setting what he wants to drink.
I can only portray a few approaches, and I don't know if they really are:
1. Returning an empty resource
The client discovers a link to / resource with a link to / resource / create and the relation "create". GET to / resource / create returns an empty resource (all attributes are empty) and a link to / resource / create with the relation "post". The client then sets the values for all attributes and POST data to / resource / create, which returns 201 (created). This means that CRUD operations are not located at the endpoint of the resource, but in the URI, for example / resource / create, and that the client can set attributes that the server ignores (for example, the creation date set on the server side).
2. Form return
Basically the same approach as above, despite the fact that the resource is not returned, but some kind of meta-information about which fields should be placed and which data types should have attributes. Like in this example. However, the creation endpoint is not on / resource, but on / resource / create
3. Creating by updating
POST to / resource immediately creates an empty resource and returns a link to this resource. Then the client can follow this link to update the resource with the necessary data that performs the PUT.
So, what is the best approach that still follows the HATEOAs paradigm and why do all of these tutorials (and even books like REST in Practice) omit this problem?
:
, API Sun Cloud API "" REST HATEOAS API. , . . , .