On 11/12/2009 14:21, Santiago Pericas-Geertsen wrote:
> 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?
I don't have a good example unfortunately. I only came across them more
recently.
>
>> 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?
I would guess the goal would be to create as flexible a design as
possible. Given that all the listed variants have some level of use out
there it would seem a good idea to at least be sure we are not excluding
them even if we don't have explicit support.
>
>> ...
>> * 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.
That would be good.
>
>> "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?
More of a general issue; but it seems to be made worse with HATEOAS in
some ways as the user can end up with too many options.
>
>> "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? :)
Perhaps, I did have a think about this over night. I guess there is no
difference between a link header and a link in the entity. So for the
moment I am coming down in the side of it being m0. My thinking is that
the state transition are the data rather than describing the data in
some way. I could if course be very wrong! :-)
Gerard
>
> -- Santiago
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
--
Gerard Davison | Senior Principal Software Engineer | +44 118 924 5095
Oracle JDeveloper Web Service, Spring, Weblogic SCA Tooling Development
Oracle Corporation UK Ltd is a company incorporated in England& Wales.
Company Reg. No. 1782505.
Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.
Blog http://kingsfleet.blogspot.com Twitter kingsfleet