On Apr 5, 2011, at 7:24 PM, Arthur Yeo wrote:
> 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.
The problem here is message self-descriptiveness. The meaning of your POST depends on the semantics of the resource. IOW, you are not saying what you want (no payload) and instead use the non-visible semantics of the resource to be the semantics of your 'operation'.
Of course it 'works' (as in "gets the job done") but it is RPC, not REST. (Not that this is inherently bad...you just need to understand the tradeoffs involved)
Jan
> 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.