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.