On Feb 29, 2008, at 4:13 PM, Martin Grotzke wrote:
> Hi Paul,
>
> thanx for your response and valuable hints! I had a look at the
> resources you referenced and have read a bit more about partial
> updates
> and PATCH. As a result I'm thinking now, that partial updates /
> PATCH is
> probably a bit too far away from standard RESTful operation/procedures
> and might lead to interoperability issues and require a relatively
> high
> effort for client developers to adapt to the API (if they would
> want to
> update only parts of the representation).
Yes, until this gets nailed down the interop is an issue. If you have
some control over the client side then it might be OK. It would still
be nice to provide some experimental functionality in Jersey for
client/server.
> So I'm more on the way now that the data, that shall be updated
> separately is so important, that it can be made available as a
> separate
> (subresource), so no partial updates or PATCH is required.
>
Right. This is a very common approach. IMHO an exemplar in this
approach is Microsofts's RESTful robotics framework (yes it uses SOAP
as well as HTTP! but not in the "conventional" way in a RESTful
uniform interface way, very educational in that respect). There is
also some really good ideas on service composition.
> To give an example: we have a user resource, and it shall be
> possible to
> change the password for the user. So now I would prefer to provide a
> POST to /users/{username}/password.
>
PUT would be more appropriate, as you are updating.
I am wondering if it may be possible to automatically derive at
runtime some hierarchy from XML schema or JAXB beans to help automate
this type of thing...
Paul.
> Thanx again,
> cheers,
> Martin
>
>
> On Fri, 2008-02-29 at 12:21 +0100, Paul Sandoz wrote:
>> Hi Martin,
>>
>> Martin Grotzke wrote:
>>> Hi,
>>>
>>> I want to provide partial updates for a resource. I only read about
>>> partial updates and the PATCH method until now, without having
>>> tried one
>>> of both.
>>>
>>> Are there any experiences / suggestions regarding the
>>> implementation of
>>> such a functionality with jsr311/jersey?
>>>
>>
>> It is easy to define the @PATCH annotation :-)
>>
>> @Target({ElementType.METHOD})
>> @Retention(RetentionPolicy.RUNTIME)
>> @HttpMethod("PATCH")
>> public @interface PATCH {
>> }
>>
>> then i think there need to be appropriate message body readers
>> supporting Java types for PATCH representations. IMHO that is the
>> tricky
>> part of PATCH, what exactly should be the diff format. James Snell
>> has
>> some good blogs on the subject [1]. An XQuery approach could be
>> interesting. You might be able to use the nux API [2] for that.
>>
>> Paul.
>>
>> [1] http://www.snellspace.com/wp/?cat=45
>> [2] http://dsd.lbl.gov/nux/
>>