On Jan 13, 2010, at 10:45 AM, gerard davison wrote:
>> Thanks for taking the time to review this. Some of the material in those wikis is out of date already. In particular, I've run into some problems on the client side when using these type of references, so I decided to avoid this type of serialization for now.
>>
>
> Can you be more specific, I have solved some of these problem when playing about and would be interesting to hear what you were stuck on. Client side is much easier if you just for got resources as I described.
For certain operations, I have found that it's easier for the client to have a similar model to the server. Having a model with "references" complicates a few things. However, I think it's because of where I am in the analysis; I hope to bring these back into my analysis soon.
>>> In the section "Serialization By Reference" you have an annotation that breaks references to object. The only problem with this that I see is that perhaps it doesn't give a consistent programming model. When I have been playing in this area I have explicitly used the resources in the model so you example becomes:
>>>
>>> public class CustomerBean
>>> {
>>> public List<AddressResource> addresses;
>>> }
>>>
>> Interesting. I was always separating resources (controller) from the beans (model). Let me think about this one more.
>>
>
>
> Yeah I wanted to do that, and then gave up as I just ended up working against REST principles and making things more complicated. For HATEOAS to work the model and controller are one in the same. (Not 100% sure, someone can tell me why I am wrong on this one)
In my current design (which can change any minute, mind you :) the @Action's are part of a server-side controller/resource, and not part of the model --this separation appears to work quite well if you want the runtime system to manage actions and action sets.
There's a similar client-side controller in the form of a Java interface which is used to generate a dynamic proxy for the client. Again, the separation of model and controller seems to result in a clean design.
-- Santiago
>>> For example it is perfectly possibly that the addresses could like in a different space. It does though restrict your server side design though, and does bring into question whether AddressResource should be a class/ interface / both. (I guess that is what I was getting at in http://kingsfleet.blogspot.com/2009/10/proxy-client-based-on-jersey-with-bit.html, but I haven't written up the server side yet)
>>>
>>> Thanks again for writing it up as you go,
>>>
>>> Gerard
>>>
>>>
>>> On 11/12/2009 19:31, Santiago Pericas-Geertsen wrote:
>>>
>>>> Gerard,
>>>>
>>>> Added section to [1] about use cases. Also, started new wiki [2] to develop a complete example that includes some exploration (mostly braindumping) of ideas/solutions.
>>>>
>>>> -- Santiago
>>>>
>>>> [1] http://wikis.sun.com/display/Jersey/Hypermedia+and+Client+APIs
>>>> [2] http://wikis.sun.com/display/Jersey/Hypermedia+Examples
>>>>
>>>> On Dec 11, 2009, at 12:56 PM, gerard davison wrote:
>>>>
>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>