users@jersey.java.net

[Jersey] Re: Migrating RPC to REST

From: Arthur Yeo <artyyeo_at_gmail.com>
Date: Tue, 5 Apr 2011 09:59:04 -0700

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.