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