Jason,
don't get me wrong, but my question was not about finding any technical
solution. As a JAX-RS 2.0 EG member I certainly know lots of technical
ways to solve it basing on http mis-use. What this discussion was about
instead was: Is there some common sense for a *RESTful* (not just HTTP)
solution to the problem. As command passing (neither by special headers
nor by command entities) is not RESTful, obviously there is not, as Jan
pointed out yesterday. A solution could be the COPY noun of WebDAV, but
some people tend to say it is not RESTful since it not transferring any
state at all. So thank you for all your indeed good ideas, but they just
describe technical solutions, not an answer to the original question
about being RESTful.
Regards
Markus
From: Jason Erickson [mailto:jason_at_jasonerickson.com]
Sent: Dienstag, 5. April 2011 19:17
To: users_at_jersey.java.net
Subject: [Jersey] Re: Migrating RPC to REST
I think I see your dilemma. The problem is that while SOAP is well
suited to RPC-style stuff, REST is very noun-focused. There is a very
limited vocabulary of verbs and those all typically have to do with
acting on nouns. Update a person, get a list of buildings, create a new
account, etc. The good thing about REST is that, at least for many
applications, those few verbs cover 90% of what you want to do anyway so
it's a very nice fit. But you still have that 10% to deal with.
There is no technical reason you couldn't do this with a POST. Return a
201 with the Location in the response pointing to a URL that would
retrieve all of those new rows you just created. The client might
choose to retrieve them, but is certainly not obligated to do so.
If a single URL could not express all of the stuff that is created by
the POST request, then think about the noun as a "Command" or a
"Message". Then you might have a path like this: /ws/system/commands.
You could POST a command to that URL that would cause the action you are
talking about. Then you could store the command in a table or file or
whatever and return a Location that pointed to the command (not to all
the side-effects of issuing the command).
Now, if you don't want to store that stuff, just returning a 204 or 200
with something about the status is fine, too. There is no rule that
says that a POST has to have a corresponding GET.
On Apr 5, 2011, at 9:45 AM, Markus Karg 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.