Please see inlined.
I am thinking the same as Santiago here. It seems in some cases, being pure
REST is not the way to go, and as Roy and others have said in some comments
on forum posts and here on this list... REST is not always the right
architecture. It's a shame tho, and hence why I've said a few times, and I
notice on the rest-discuss list a few others too have said.. what we need
then is a HTTP api (I think you coined that Jan).. something that we can get
"buy in" from the developer community at large, regardless of
language/platform, that is mostly RESTful, in that it uses HTTP (or perhaps
not tied to HTTP), the methods, and we can basically use it in place of
xml-rpc/web services. It's much easier to work with and with so many now
doing it like this anyway (due to not being completely RESTful), perhaps we
look at some way to make a cousin to REST that can take off and become a
newer/better API choice over web services and being pure REST.
I never said that REST is the best approach for *everthing*. I just said
that REST is the best approach for many project (in fact for nearly each I
attended in the past decades, reflecting the problems we discovered with the
solution done in that days). As a result, it *might* certainly be the case
that the optimal solution for some problems is *not* RESTful at all but is a
mixture. But for the cart example I don't see that a mixture is needed as
your solution IS RESTful: As I wrote in my last posting, you *can* provide a
RESTful API that stores carts permanently on the server as soon as this is a
business requirement. I just didn't expect that requirement unless you told
it, so I didn't see the *need* to do that. It is a difference if you have a
short-term (DB-typical) transaction ("session state"), or a long-term
(keeping carts in the basement over night) transaction ("resource state").
You need to look at that from the business requirements level to see the
difference, as technically there is none!
That said, I can see how REST could be used for the cart example... but
(always a but) I am failing to see how anyone other than an individual
client would want to use a pure rest implementation since the burden of
maintaining state is put on them. By anyone other than individual, I
basically mean a web site... where they cater to end users.. and thus have
to deal with the scaling issues that maintaining state will put on them.
It's the HttpSession/replication nightmare all over again.. although these
days we're far better prepared to scale state than back in the late 90s when
servlets and HttpSession were first being developed with and not many people
had an idea how to replicate session data to ensure fault tolerance and
load.
This is a particular need of your particular customers. Ours do not expect
us to store their cars over night in the basement. So they have no problem
with storing carts on their HDDs. Moreover, they love storing the carts on
their disk since they can carry it around with them on their USB stick or
send it by skype or email or print it or. (actually we don't have neither a
shop nor carts but different data objects, this is just an analogy). You
shouldn't imply that all kinds of applications have the same business
requirements that you have, nor that other customers are like your
customers: There are lots of pure RESTful applications, and people actually
love them (if not why should anybody accept or build them?)!
--- On Fri, 2/19/10, Santiago Pericas-Geertsen
<Santiago.Pericasgeertsen_at_Sun.COM> wrote:
From: Santiago Pericas-Geertsen <Santiago.Pericasgeertsen_at_Sun.COM>
Subject: Re: [Jersey] RESTful Ordering (was: JAX-RS == REST? Or not? (was
Re: [Jersey] What HATEOAS actually means))
To: users_at_jersey.dev.java.net
Date: Friday, February 19, 2010, 5:38 AM
Jan,
If the meaning of the message must be completely independent of the server's
state, then this makes perfect sense. I suppose that orders should include
item prices and other information to avoid depending on any other server
state.
This is a much stronger constraint than session state independence, or
simply a different interpretation of what I understood as a session. And it
does appear to introduce some complexity for certain systems and may be the
reason why many things out there are not REST in this sense.
Thanks for the clarification.
-- Santiago
On Feb 19, 2010, at 2:52 AM, Jan Algermissen wrote:
> All,
>
> here is the issue with the POST on the shopping cart to place the order:
>
> REST constrains messages to be stateless. The meaning of the message must
not depend on server side state.
>
> The meaning of the message depends on the semantics of the resource (which
is constrained to be constant over time) but it must not depend on the
resource's state at some point in time.
>
> This is why, in order to correctly reflect the intention to buy A,B and C
(see earlier example[1]) these items must be enumerated in the POST body.
Just POSTing to the cart resource makes the meaning of the message a
function of the semantics of the resource BUT NOT of its current state.
>
> Jan
>
> [1] https://jersey.dev.java.net/servlets/ReadMsg?list=users
<
https://jersey.dev.java.net/servlets/ReadMsg?list=users&msgNo=10255>
&msgNo=10255
>
>
>
> On Feb 18, 2010, at 4:03 PM, Jan Algermissen wrote:
>
>>
>> On Feb 18, 2010, at 3:36 PM, Jan Algermissen wrote:
>>
>>>
>>> On Feb 18, 2010, at 3:32 PM, Jan Algermissen wrote:
>>>
>>>>
>>>>
>>>> for purposes of visibility but I just saw Mark B mentioning that and
cannot give an explanation.
>>>>
>>>
>>> Here is the short thread:
<
http://tech.groups.yahoo.com/group/rest-discuss/message/13627>
>>
>> Re-reading that, there are two issues
>>
>> - I am not sure I agree and if I do I cannot completely explain on what
grounds
>> - There indeed is an issue with how much the client wants to rely on the
server
>> maintining stability of the cart (or order) when it comes to
>> me hitting 'submit'. IOW, how can I be sure the resource state is the
same
>> when the POST arives as it was when I sent the request
>> - the issue has consequences on the design of e.g. the payment
'operation'
>> that started this thread.
>> Mark's position emphasizes that the complete order should be sent to a
>> payment resource instead of invoking a POST-tunneled pay() on the order.
>>
>> Jan
>>
>>>
>>>
>>>
>>>> Jan
>>>>
>>>>
>>>>> In my view, creating resources identifiers for things of interest is
precisely how you avoid relying on sessions. The service will associate that
resource identifier with objects stored in a database, and there's no need
for the client to store anything once it gets that resource identifier.
>>>>>
>>>>> By analogy, let's say you call your insurance company to file a claim.
The first time you call, you give them all your info and they give you a
claim number (a resource identifier!). Next time you call, it does not
really matter who you talk to as long as you give them the claim number and
they can look it up in their database. Without a claim number, you'd need to
start all over or talk to the same person to continue the session --and that
wouldn't very RESTful.
>>>>>
>>>>> I'm not sure I can comment on your API specifically, but I believe you
can build the system the way you want without relying on sessions.
>>>>>
>>>>> -- Santiago
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>
>>>> -----------------------------------
>>>> 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
>>>>
>>>
>>> -----------------------------------
>>> 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
>>>
>>
>> -----------------------------------
>> 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
>>
>
> -----------------------------------
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: users-help_at_jersey.dev.java.net