The resource state, obviously. It is that what has to be transferred
according to REST. But if you forward a COMMAND, that is not a resource's
state, but a request to the service to do something. It is RPC.
From: Arthur Yeo [mailto:artyyeo_at_gmail.com]
Sent: Donnerstag, 7. April 2011 21:04
To: users_at_jersey.java.net
Cc: Markus Karg
Subject: [Jersey] Re: Migrating RPC to REST
Markus,
May I ask which state are you worried about:
1. your application state or
2. the resource state?
--
On Thu, Apr 7, 2011 at 11:43 AM, Markus Karg <markus.karg_at_gmx.net> wrote:
Thank you for posting this example. It expresses exactly very well the
"don't transfer twice" problem.
Unfortunately, I do not see that your solution is RESTful, as REST implies a
representational STATE transfer, but with your POST you do not transfer
STATE but you transfer a COMMAND. So that inherently is RPC and such is not
REST. That's why I started this thread: I do not see a RESTful solution, so
the REST hypothesis clearly is inefficient in this case.
> -----Original Message-----
> From: Conal Tuohy [mailto:conal.tuohy_at_gmail.com] On Behalf Of Conal
> Tuohy
> Sent: Donnerstag, 7. April 2011 00:32
> To: users_at_jersey.java.net
> Subject: [Jersey] Re: Migrating RPC to REST
>
> Markus, I think there probably are RESTful solutions to your problem,
> and I understand you are interested in the general case rather than
> your
> particular case (with the stored procedure), but others have already
> pointed out that you would need to be more specific about the problem
> (i.e. the domain itself) to elicit those solutions, because, in short,
> any RESTful solution will need to represent your domain model. So long
> as the problem is posed in the abstract, or in terms of "running a
> stored procedure" (which is too low-level) then the business domain
> remains obscure, yet the domain is the key to formulating a concrete
> solution.
>
> So I will make up an example:
>
> A supermarket shopper has a shopping list which they can save and
> reuse.
> I have one of these with my local supermarket, Coles. Every few weeks I
> can go on to the Coles website, maybe tweak the list a little, adding
> an
> item, removing an item, and then click "Buy Now" which I imagine
> transfers my shopping list to another list (a "packing list") which
> someone at the Coles warehouse uses to pack up some cardboard boxes for
> me.
>
> Is there a RESTful solution to this which doesn't require my browser to
> download my entire list and re-upload it?
>
> I think there is. I don't need to upload the list, because it is
> ALREADY
> there on the server. If my shopping list was linked to an associated
> resource (an "ordering service") which I could POST to to say "Create a
> order (from this list) and get packing!", then that would IMHO be
> perfectly RESTful.
>
> e.g. imagine my shopping list had a representation like so:
>
> GET /my-shopping-list/
>
> <shopping create-order="new-order">
> <item>beans</item>
> <item>milk</item>
> etc.
> </shopping>
>
> Then I could POST
>
> POST /my-shopping-list/new-order
>
> ... and it would create an order from my list, returning me a redirect
> to: /my-orders/order-3
>
> GET /my-orders/order-3
>
> <order date="2011-04-07" number="3">
> <item>beans</item>
> <item>milk</item>
> etc.
> </order>
>
>
>
> On 06/04/11 21:30, Markus Karg wrote:
> > Marek,
> >
> > the intention of the question is a theoretical interest in REST
> idioms used by Jersey users. There is no technical problem which I
> would be unable to solve on my own, I just wanted to get an overview of
> the idioms and patterns used by Jersey users to solve problems like
> these. So the discussion is not: "Why to do REST?" as doing REST is the
> given constant in this paradigma.
> >
> > I want to find out whether there is a common sense (pattern or idiom)
> among the Jersey users for solving any member of this class of problems
> ("copying data inside of the server without GETting it first and
> PUTting it later"). The problem is common and not tied to one
> particular, actual business domain use case.
> >
> > As Jan correctly pointed out, without any transfer, it wouldn't be
> RESTful by definition. So the end of the discussion is reached
> obviously: There cannot exist a valid solution, since REST *must*
> forward the representational state (a command, in any form, is not a
> representational state).
> >
> > To sum up:
> >
> > In WebDAV, COPY is the best technical approach, but it is not
> RESTful.
> >
> > In pure HTTP, PUT with some kind of additional source URL would be
> the best technical approach, but it is not RESTful.
> >
> > To be RESTful, the source object *must* get transferred by
> definition, so in this class of problems, it must get copied twice.
> With REST applied to http this means, GET and PUT of an unchanged
> object. A technical help for performance is using a caching proxy most
> near to the client to at least prevent a GET content transfer over the
> whole web. AFAIK a PUT cannot be optimized in that way as it must not
> store into a cache (maybe I am wrong with that).
> >
> > So now I know what I wanted to know: There cannot be a RESTful
> solution. If it must be RESTful, then it *must* copy the source twice
> over the LAN.
> >
> > Thanks to all participiants. :-)
> >
> > Regards
> > Markus
> >
> > -----Original Message-----
> > From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> > Sent: Mittwoch, 6. April 2011 12:03
> > To: users_at_jersey.java.net
> > Cc: Markus Karg; 'Arthur Yeo'
> > Subject: [Jersey] Re: Migrating RPC to REST
> >
> > Hi Markus,
> >
> > Have you considered to actually NOT replacing this stored procedure
> call with RESTful architecture? Perhaps I am missing
> > some important piece of information from your use case, yet from what
> was discussed here it seems to me that in this
> > case RCP-style call may be actually more suitable for your use case.
> >
> > What features of the RESTful architecture do you want to leverage in
> this use case (scalability, cacheability, loose
> > coupling, transparency ...)? IOW, why do you want to expose the
> stored procedure in a RESTful way?
> >
> > Marek
> >
> > P.S. I agree with what Jan wrote earlier - if you really need to
> redesign this use case in a RESTful way, you need to
> > look at the operation as a (temporal) service resource in the context
> of it's domain. Then you might be able to properly
> > define the resource including the URI scheme, HTTP operations and
> payloads etc. It is however difficult to make concrete
> > proposal based on the "INSERT FROM SELECT" information :)
> >
> > On 04/05/2011 10:46 PM, Markus Karg wrote:
> >> You're right, but that doesn't solve the problem that your proposal
> is not RESTful: A PUT must provide the source entity
> >> as a body. How will you provide the URL of the source without
> breaking the rules of RESTfulness? See, the question was
> >> not "How to call a stored procedure using http?" but "How to call a
> stored procedure in a RESTful way?".
> >>
> >>
> >>
> >> Regards
> >>
> >> Markus
> >>
> >>
> >>
> >> *From:*Arthur Yeo [mailto:artyyeo_at_gmail.com]
> >> *Sent:* Dienstag, 5. April 2011 20:00
> >> *To:* users_at_jersey.java.net
> >> *Cc:* Markus Karg
> >> *Subject:* Re: [Jersey] Re: Migrating RPC to REST
> >>
> >>
> >>
> >> If the URL species the PK of the INSERT, which I take it to mean the
> unique ID for the new rsrc, then you should be
> >> using a PUT instead of a POST.
> >>
> >> On Tue, Apr 5, 2011 at 10:52 AM, Markus
> Karg<markus.karg_at_gmx.net<mailto:markus.karg_at_gmx.net>> wrote:
> >>
> >> Arthur,
> >>
> >>
> >>
> >> there is one thing you are missing: How to tell POST where to take
> the data from (i. e. the PK used in the WHERE clause
> >> of the SELECT)? Obviously you need to pass it as some kind of header
> with the POST (the URL of the POST is the PK of the
> >> INSERT, not the PK of the SELECT). So it is not RESTful, as Jan
> pointed out this afternoon already.
> >>
> >>
> >>
> >> Regards
> >>
> >> Markus
> >>
> >>
> >>
> >> *From:*Arthur Yeo
> [mailto:artyyeo_at_gmail.com<mailto:artyyeo_at_gmail.com>]
> >>
> >> *Sent:* Dienstag, 5. April 2011 19:24
> >> *To:* Markus Karg
> >>
> >> *Cc:* users_at_jersey.java.net<mailto:users_at_jersey.java.net>
> >>
> >>
> >> *Subject:* Re: [Jersey] Re: Migrating RPC to REST
> >>
> >>
> >>
> >> If the data is self-generated within the sproc from a SELECT and the
> sproc is using that data to do an INSERT, I do not
> >> see a reason to put anything in the POST, not unless you have some
> params.
> >>
> >>
> >>
> >> You are creating a new resource with your POST which is carried out
> by your original sproc. There is no payload in the
> >> POST for this case.
> >>
> >> Your POST, in this case, is even lighter weight than ordinary POST
> that has a payload.
> >>
> >> You did not change the meaning of a POST. Just make sure you return
> some kind of identification back to the frontend for
> >> the creation of that new rsrc.
> >>
> >>
> >>
> >> On Tue, Apr 5, 2011 at 10:11 AM, Markus
> Karg<markus.karg_at_gmx.net<mailto:markus.karg_at_gmx.net>> wrote:
> >>
> >> Arthur,
> >>
> >>
> >>
> >> if you want to do a POST, what actually do you like to send as the
> body? As Jan correctly pointed out, sending an empty
> >> body is not RESTful.
> >>
> >>
> >>
> >> Regards
> >>
> >> Markus
> >>
> >>
> >>
> >> *From:*Arthur Yeo
> [mailto:artyyeo_at_gmail.com<mailto:artyyeo_at_gmail.com>]
> >> *Sent:* Dienstag, 5. April 2011 18:59
> >> *To:* users_at_jersey.java.net<mailto:users_at_jersey.java.net>
> >> *Cc:* Markus Karg
> >> *Subject:* Re: [Jersey] Re: Migrating RPC to REST
> >>
> >>
> >>
> >> Then, I am not understanding your concerns.
> >>
> >> If there's already an sproc to do an INSERT based on some SELECT,
> all you have to do is to either do a POST/PUT over
> >> JDBC to call that sproc, depending on your application's needs.
> >>
> >> I do not see how the data is is moved twice? Please elaborate.
> >>
> >>
> >>
> >> On Tue, Apr 5, 2011 at 9:45 AM, Markus
> Karg<markus.karg_at_gmx.net<mailto:markus.karg_at_gmx.net>> wrote:
> >>
> >> I never said that I want to break up the INSERT FROM SELECT. In fact
> I still
> >> want to call the stored procedure. But I want to discuss a possibly
> RESTful
> >> interface for calling a stored procedure.
> >>
> >>> -----Original Message-----
> >>> From: Arthur Yeo
> [mailto:artyyeo_at_gmail.com<mailto:artyyeo_at_gmail.com>]
> >>> Sent: Dienstag, 5. April 2011 16:50
> >>> To: users_at_jersey.java.net<mailto:users_at_jersey.java.net>
> >>> Subject: [Jersey] Re: Migrating RPC to REST
> >>>
> >>> Is there a reason why you have to break up the INSERT and SELECT? I
> >>> thot u said these are all handled in a sproc?
> >>>
> >>>
> >>>
> >>> On Tuesday, April 5, 2011, Markus
> Karg<karg_at_quipsy.de<mailto:karg_at_quipsy.de>> wrote:
> >>>> Hello Jersey Community, we're in the process of migrating some
> >>> functionality from RPC to REST and stuck with an issue we'd like to
> >>> discuss with you. :-) One of the business procedures we're
> migrating
> >>> was implemented as a stored procedure. It actually did nothing
> special
> >>> but just provided a copy of a rather big amount of records in a
> single
> >>> transaction. You can think of it in terms of SQL as "INSERT FROM
> >>> SELECT". In JAX-WS's RPC style it was just wrapped with a method of
> a
> >>> @WebService that called the stored procedure. But how to convert
> this
> >>> to a RESTful style in JAX-RS? Our initial idea was to do a http GET
> to
> >>> load the source, then forward that same XML body to a http POST.
> >>> Obviously that is RESTful and simple to do, but it means moving a
> >>> really, really big bunch of information twice over the web, just
> for
> >>> the sake of RESTfulness (and it would be two transactions,
> obviously).
> >>> Has anybody an idea how to RESTfully model this use case, so that
> the
> >>> data is not transferred at all but we still can just call the
> existing
> >>> stored procedure? The only idea we had would be doing RPC style,
> like
> >>> http post with a Location-header pointing to the source. But
> obviously
> >>> that is not very RESTful. Any ideas? :-) RegardsMarkus
> >>>
> >>> --
> >>> Arthur Y.
> >>
> >>
> >>
> >> --
> >> Arthur Y.
> >>
> >>
> >>
> >>
> >> --
> >> Arthur Y.
> >>
> >>
> >>
> >>
> >> --
> >> Arthur Y.
> >>
>
>
> --
> Conal Tuohy
> eResearch Business Analyst
> Victorian eResearch Strategic Initiative
> +61-466324297 <tel:%2B61-466324297>
--
Arthur Y.