On Feb 15, 2010, at 3:13 PM, Markus Karg wrote:
>> 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.
>
> I think the problem is the opposite: We are discussing things that just are
> not REST, while our job actually is to define a Java API for REST. So we
> cannot discuss the example, as it is not RESTful. It wouldn't make sense. We
> all are graduated, so we should be possible to discuss abstract application
> architecture without the need to discuss particular use cases. Shouldn't we?
Sure, but ultimately people want to solve real and concrete problems.
>> 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 it is not common, why using it as an example then?
not uncommon?
>
>> 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?
>
> The example is wrong. Why do you want to upload the order while the client
> actually still is adding items?
Because I may send an order today, and tomorrow change my mind and want to add something else?
> And why do you want to have items be part of
> the order instead of each being its own resource instance (Fielding also
> told us to not build aggregates where references will server pretty well).
Product are resources, ordering X quantity of product Y is really part of an order and not something interesting outside of a particular order (i.e., not a resource).
> As long as the client is in the process of adding items, the state of the
> workflow is not changing. So why pushing something up to the server? For
> what?
>
> Do you see what I mean with "the example is not the problem, since it is not
> RESTful"?
I don't, sorry. Placing an order today, and changing it tomorrow has nothing to do with being RESTful. It's just what real-world systems have to cope with. As engineers, we can't just say "we won't implement that because it's not RESTful".
>> 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.
>
> There is no problem in making the server do anything as a reaction to a PUT,
> as you only have one PUT. Remember, you have no need to upload the order
> unless it contains all 300 items. Does a HTML form get uploaded unless all
> 300 input fields are filles out? NOPE! So why wanting to do so?
See above.
>
>> 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 :)
>
> Well, as I tried to point out in my blog, the definition of REST is
> (luckily) not dependent on what your or me or anybody THINKs, as there is
> exactly one and only one exact and unambiguous defition given in the
> dissertation by Mr Fielding. And that definition does not contain actions or
> buttons, so they are NOT RESTful. If you still doubt it, read Fielding's
> blog http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
> that points out that actions of any form are NOT RESTful as they are RPC.
Having a discussion with Roy would be interesting. He may indeed think this is not RESTful, but I'm interested in understanding the reasons. But, more importantly, understand how frameworks like Jersey can help developers with HATEOAS.
-- Santiago