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
>
>
--
Arthur Y.