Hi Gerard,
A few questions about your e-mail,
> 1. Implicit / Derived links
>
> 1.1 Implicit (aka Legacy services)
>
> ...
> 1.2 Derived
>
> ...
> 2. Explicit links
>
> ...
I think (1) and (2) are clear.
> 3. Out of band links.
>
> 3.1 HTTP-Headers
>
> For example using HTTP Header Linking:
>
> http://www.mnot.net/drafts/draft-nottingham-http-link-header-00.txt
>
> Of course this binds your implementation to HTTP in a way you might
> live to regret at a later stage. Think of all the work that goes
> into supporting SOAP over non HTTP protocols.
How would the representation of an <employee> look like using HTTP
headers in your view?
> In general it should be possible for a generic client to support of
> all these options
Do you consider supporting all these options a goal?
> ...
> * Use cases *
>
> It would be good to have a list of use cases that we are trying to
> support.
Yes, shall we use a wiki for that? I can start it.
> "The client of the API would like a static interface with which to
> program againsts. For the clients point of view this enabled them to
> use existing coding tools that understand java interfaces and beans."
+1
> "The publisher of the API would like to define a subset of the WADL/
> IDL for a client to use in a particular case. This would allow them
> to help guide client in Java through a particular route in the API. "
Is this related to HATEOAS or a more general issue?
> "The client of the API should be able to deal with the evolution of
> server data model"
+1
All these UCs should help us derive a list of requirements (which we
sort of started already, but it's likely incomplete).
> entity => m0 or instance data
> wadl => m1 or meta data
> links in http headers => is this m0 or m1? I am not sure we it
> contains both instance references and information about the
> structure of the model
m0.5? :)
-- Santiago