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> 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]
> *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.
>
--
Arthur Y.