> >> We need to come with a number of patterns that can be applied to
> use-cases and have corresponding prototype implementations and from all
> that we will be able to hopefully define really good client and server
> hypermedia API support!
Why not doing the reverse way and first accept what Fielding says what REST
/ HATEOAS is and what definitively not is (links in headers, action-type
URIs)? THEN we should define APIs around REAL REST. Ain't that much faster?
:-)
> Perhaps it would help to spell out what we are trying to achieve. We
> want to build a client-side API that helps developers work with
> hypermedia-driven web applications. We believe its OK for client
> applications to bind at design-time to link types ("actions") but are
> aiming to delay other types of binding (URI, HTTP method) until
> runtime. We are using WADL as a forms meta language to decouple the
> client runtime from other representation media types.
You approach is really respectable and pragmatically, but not RESTful. And I
thought Jersey's target is to implement JAX-RS, which is an API for REST?
What you try to do is a second http-RPC besides SOAP. If you want RPC, do
SOAP. That is a valid idea, but it is not REST. That's why I said, the API
(in the current proposal) is useless: If I would like to get RPC, I would do
SOAP.
> The first stab at this uses HTTP Link headers because its easier to
> find and parse those than links embedded in representations but we'll
> get there eventually.
...which is diametral to what Fielding said about that, and since he
invented REST, he is right by definition. Only parsing links inside of the
representation is REST according to his him, so we should start with that,
as we (again) want to provide a REST API, not "ANY" http-RPC API.
> The Jersey "action" URIs are roughly
> equivalent to HTML form actions and I don't see these as being
> ephemeral: the results may change depending on server state but the
> client can hold on to a form as long as it likes before submitting it.
This is wrong. Jersey's "action" URIs are *not* the equivalent to HTML form
actions, as a HTML form is the request to process an uploaded entity. The
Jersey example contain actions not related to any upload. As Fielding says,
the server shall save not state but (it is stateless), how should the server
know what information to process if not uploading it? So in the end, what
Jersey's "action" URIs are doing is *not* asking the server to process the
uploaded data, but instead to just call a server side method that does
*anything* -- which is not REST but RPC.
Regards
Markus