Jan,
I suspect that those two camps started when architects/programmers began using the technology in the real world, beyond samples. I doubt every RESTafarian would regard REST APIs such as Sun Cloud, Flickr, etc. as pure REST. Perhaps this is due to one camp not communicating well with the other (lack of a best practices document?); perhaps this is simply an evolution of the technology.
Of course, we don't want the technology to morph into something that it isn't, hence the importance of these discussions! As Paul has stated, I think it's important to bring this discussion down to real problem solving and real prototypes and running examples. This will simplify communication between the two camps.
Let's look at the purchase order example again. Let's say I have 300-field order, which is not uncommon in real examples. If the only way a client can affect the application state is by PUTting a new representation of this order, then the implementation of this system can get quite hairy. If there are N states and M fields in the order that can trigger those N states, then (i) the client needs to send a complete order (even if only one field is updated) and (ii) the server needs to compare and analyze the new representation against the existing one to determine the transition. This may be "pure" REST for some, but practical it isn't. Wouldn't it be easier to hint the server about what's going on?
So PATCH was invented for partial updates ... even though Roy himself said it's OK to use POST in those cases [1]. If there are fields in the representations that can be used to trigger state changes, then PATCH may work. But as Tim pointed out [2], in some cases, you're really asking for some action (what Tim and Roy refer to as buttons in their blogs) to be carried out, perhaps even asynchronously, that does not quite map to a client representation change. I don't think these buttons/actions make any system more or less REST (although I perfectly understand how they can trigger these long discussions :)
-- Santiago
[1]
http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
[2]
http://www.tbray.org/ongoing/When/200x/2009/03/20/Rest-Casuistry
On Feb 15, 2010, at 5:56 AM, Jan Algermissen wrote:
> Paul,
>
> On Feb 15, 2010, at 11:46 AM, Paul Sandoz wrote:
>
>>
>> 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!
>>
>
> Recent discussions have made me think that among the more 'advanced' RESTafarians there seem to exist two camps that have a completely different view on how machine-to-machine hypermedia should be designed. Hence for example my apparent complete non-grasping of what it is you are trying to solve with the Jersey proposal (I just do not know that problem).
>
> I have brainstormed that here a bit: http://www.nordsc.com/blog/?p=358 and make sure you follow the links and read about Mike Amundsen's 'transient URIs' and Ian S. Robinson's 'ephemeral URIs'. Please also read my comment on Ian's blog (once he moderated it). My thinking likely only comes across in the complete context.
>
> I have a hunch that a) there is a very important aspect behind the 'divide' and b) it is vital to understand each other and reach a real conclusion (wrt Jersey especially).
>
>
> Jan
>
>
>
>
>
>> Paul.
>>
>> [*] What ever you might think of it one thing it is not is RPC.
>>
>>
>> On Feb 14, 2010, at 4:32 PM, Markus Karg wrote:
>>
>>> For those interested in the current hypermedia discussion, I'd like to point you to my latest blog entry about "What HATEOAS actually means". It might be interesting to follow its links into Fielding's dissertation so everybody understands what the recent discussion was / is about. It also explains why I think that the current Jersey proposal is invalid, since it is not implementing HATEOAS from the view of the dissertation but more from a pragmatic aspect of doing RPC via http.
>>>
>>> http://weblogs.java.net/blog/mkarg/archive/2010/02/14/what-hateoas-actually-means
>>>
>>> Regards
>>> Markus
>>
>
> -----------------------------------
> Jan Algermissen, Consultant
> NORD Software Consulting
>
> Mail: algermissen_at_acm.org
> Blog: http://www.nordsc.com/blog/
> Work: http://www.nordsc.com/
> -----------------------------------
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>