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.
>