users@jersey.java.net

Re: [Jersey] Advanced Query

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Mon, 23 Jun 2008 08:34:46 +0200

Hi Lars,

The Yahoo rest-discuss group contains a lot of good "restafarians".

IMHO you can create a URI that represents a 'temporary' user until
they log in either for the first time or otherwise on check out. Then
you can assign the state of the resources associated with the
temporary URI to the user-based resources associated with the user-
based URI.

Paul.

On Jun 21, 2008, at 11:19 PM, Lars Tackmann wrote:

> Hi
>
> I have a general REST question and thought I would post it here since
> this list contains allot REST wizards (if a better place exists then I
> would be happy to hear of it). Consider the following user story:
>
> A) A user access webshop and puts items into a shopping basket
> B) As each item is added the price gets updated and displayed to the
> user (advanced server side calculation rules)
> C) When the user checks out, he is created in the system and the order
> is processed.
>
> As the user is not created until the order is processed, no order can
> be persisted before this time. This requirement makes the usual CRUD
> way of doing price calculation hard (i.e. create the order, get its id
> and modify it as the user makes changes).
>
> This essentially leaves me with these options
>
> 1) POST order and get its price in return (RPC style with no server
> side changes).
> 2) Add the order as a entity body to a GET method. RFC2616 does not
> prohibits sending a message-body with a GET method (sections 5.1.1
> (Method) and 9.3 (GET) doesn't say anything a bout this).
> 3) Add the order as query data to a GET method
> 4) Use a POE (post once exactly) style price calculation
>
> I am not satisfied with any of these - option 1 seams to much RPC
> style, 2 is not really prohibited but neither is it best practice, 3
> makes the URLs ugly (there is going to be allot of data) and option 4
> seams like overkill.
>
> In general I am looking for the most RESTful solution for handling
> complicated query data - so any thoughts on which way is best or
> suggestions of different solutions will be most welcome.
>
>
>
> --
> Yours sincerely
>
> Lars Tackmann
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>