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]
Sent: Dienstag, 5. April 2011 19:24
To: Markus Karg
Cc: 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> 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]
Sent: Dienstag, 5. April 2011 18:59
To: 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> 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]
> Sent: Dienstag, 5. April 2011 16:50
> To: 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> 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.