This discussion started on users_at_jersey.dev.java.net and was moved to
rest-discuss as it is a general REST topic and less a particular Jersey
topic. Please send comments only to rest-discuss_at_yahoogroups.com but not to
users_at_jersey.dev.java.net. Thanks. :-)
As Roy Fielding pointed out several times, an API must not call itself
RESTful as long as it is not applying HATEOAS. I want to support this
constraint by adding HATEOASfulness to my future applications. One thing I
just do not understand so far about HATEOAS-via-HTTP is (and what other
people asked me when citing Fielding in this issue): How a client shall
actually know which http method to use to follow a link received with the
previous request to a RESTful server? Roy answered in his blog that the
method could be read out of the last result. But actually how?
I understand that typically one would use e. g. http "Link" headers or e. g.
XLink in XML content to model HATEOAS transformation URIs. But the problem
is that in reality neither the "Link" header nor XLink provide the
possibility to declare the http method used on that URI. So my client can
learn from the previous http request what the URI is to place an order, but
it does not see which http method must be used to place it (whether it is a
PUT or a POST for example, since both could be valid in theory). I
understand that in a perfect world, I could apply the common sense for the
CRUD-via-http pattern on that resource (PUT, GET, POST, DELETE), but it
might be not so obvious in all cases which of that methods is actually right
to achieve a particular business task, since the business use case is beyond
simple CRUD, as there might be more than one way to RESTfully model a
complex business case.
Fielding wrote in his blog that the client will learn about the http methods
by inspecting the last response, just as it learned about the possible URIs.
But how to actually achieve this in reality, aside from the purely
theoretical idea? Is the actual solution really to break down all business
cases to CRUD atoms (and such to unambiguity of http methods)?
I already searched the archive for this but could not find a working
real-world solution (maybe I used the wrong keyword when searching?).
Thanks
Markus