Jakub,
about the transaction example: It is common sense that RPC is not REST
and I do not believe that you really see a difference between "CALL
TRANSACTION" and "INVOKE RPC". So I have to disagree, not anything that
you can name is a valid resource by definition. If that would be true,
then SOAP-RPC would be REST, too (and with this, ANYTHING would be
REST), since you also can name a service and methods. Sorry but I
actually think you know way better what REST is and what is not and you
also know that it was a weak example and what "synthethic" means (doing
something around RPC that looks like REST but that actually is not).
About posting orders and creating invoices on the fly: Yes, this is
pretty pure REST and nothing in that is RPC, since the client just says
"here is my order" and the fact that this is creating an invoice is part
of the server sided process is not aware by the client. But what is
rather strange modelling is posting the word "Confirmed" instead of
posting an OrderConfirmation object. I always say: Model the world as it
is. Use the forms and nouns and verbs that exist in real world and what
you get is REST. In the real world the example would be:
POST /orders
<order>
201 CREATED
Location: /order/123
PUT /order/123
<order confirmed="true"/>
-OR-
POST /order/123/confirmation
<confirmation>
since this is what you would do in the real world: Either putting a
"Confirmed!" stamp on the order (first case) or sending a filled-out
confirmation form to your dealer. Even if you order by phone, and just
say "Yes, I confirm" what you actually doing from a business view is
posting a Confirmation (an object, not a string).
But I do not see how this relates to the original question about copying
on the server side? An invoice is not an order, so this is not creating
a copy. Also the question is: How will one know about the URI of the
created invoice, as it is not sent back (sending it back as a Location
header in the POST would be invalid http, see RFC).
BTW, if you don't think this is the right forum (I share this opinion)
why posting to this forum then? It is obvious that I have to answer on
the forum then, too. My original question was about patterns used *by
Jersey users*, which obviously is to be posted in this forum.
Regards
Markus
From: Jakub Podlesak [mailto:jakub.podlesak_at_oracle.com]
Sent: Mittwoch, 13. April 2011 18:26
To: users_at_jersey.java.net
Subject: [Jersey] Re: Migrating RPC to REST
Hi Markus,
I do not see anything artificial here. Anything what can be named (move
transaction)
can be a resource. I do not see how this breaks the REST constraints.
I understand the "transaction" word could be a red herring here, but if
you wish,
see another example bellow.
Consider a client POSTing a new Order resource to an e-store
application.
Like this:
-->
POST /orders
<order representation/>
<--
201: CREATED
Location: /orders/123
Then the client updates the state of the order:
-->
PUT /orders/234/status
Confirmed
<--
Now the e-store application is probably going to do something
to process the order behind the scenes (without being RPCish),
and the server will probably also create a new invoice resource
and attach it to the order/123. You do not want the client to control
creating
the invoice, right?
Is the above also RPCish? I do not think so.
Otherwise REST would be limited just to a client driven data store....
Anyway, i do not think the discussion really to this forum.
~Jakub
On 04/09/2011 06:27 PM, Markus Karg wrote:
What that example does is splitting up "CALL REMOTE PROCEDURE NAMED
'MOVE'" into two sub-calls "CREATE REMOTE PROCEDURE INSTANCE NAMED
'MOVE'" and "EXECUTE PROCEDURE NAMED 'MOVE'". Synthetically complicated
form of RPC via HTTP, but not REST at all.
As one thing I learned from following the discussions on rest-discuss a
clear indication of a non-RESTful application is any form of RPC.
Looking at the book excerpt obviously that is nothing else but RPC,
since what your application domain is a transaction (i. e. a method).
What the example does is nothing else but telling the server to call a
method, in a rather strange way to make it look as if it would be REST,
while it actually being not REST. It is nothing else but synthetically
wrapping a RPC by a synthetic entity. I do not see that anywhere in that
example a REPRESENTATIONAL state is transferred (Do you really want to
say your application is RESTful just because it has a synthetic
"Transaction" entity to wrap an RPC? That would be ridiculous, because
SOAP would be RESTful then!). So despite the title of the book, that
example is anything but restful. Sorry but exactly what that example
does is NOT the intetion of REST, it is just a technical cheat done to
not accept that there are domains where RPC is superior to REST (so my
summary of this week still is true).
From: Jakub Podlesak [mailto:jakub.podlesak_at_oracle.com]
Sent: Freitag, 8. April 2011 17:03
To: users_at_jersey.java.net
Subject: [Jersey] Re: Migrating RPC to REST
Hi Markus,
IIRC there was a nice example in the RESTful Web Services book [1]
of a transaction represented in REST by a transaction resource.
In your case, you probably also want to get things processed in a
transactional way.
Then you could do something like:
-->
POST /transactions
<transaction>
<state>new</state>
<operation>move</opertation> <!-- i know, skating on a thin ice
here, but this is indeed only a data on the transaction ;-) -->
<source>...</source>
<destination>...</destination>
<state>new</state>
</transaction>
<--
201: CREATED
Location: /transactions/189
The transaction resource got created, nothing else happened yet
Then to start the transaction (introduced a sub-resource to emphasis
i am not sending commands, but the resource state):
-->
PUT /transactions/189/state
started
<--
202: ACCEPTED
above you just changed the transaction resource state to "started" from
"new"
sometime later, you may want to check the state of the transaction:
-->
GET /transaction/189/state
<--
finished
What do you think?
~Jakub
[1]
http://oreilly.com/catalog/9780596529260
On 04/07/2011 09:14 PM, Markus Karg wrote:
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.