Bleh, how unRESTful! ;)
The result of a successful POST should always and only be a HTTP 201 Created status. Included with this response will be a Location header to the newly created resource. From there, you perform a GET to the uri specified in the location header (and of course can specify the "output" query string option then).
At least from my understanding of the specs/best-practices, it seems you should not be including a message body in response to a POST operation. The reason for this is because POST is NOT cacheable. The Location header informs your user agent of the newly created resource uri, which is fetched by GET and available to any caches, etc.
But, my last name is not Fielding, so what do I know. ;) Adam John D. Mitchell wrote:
Same thing. I.e., I want the result of the POST to be given in various output formats, too. John On 5/23/07, Adam Taft <[EMAIL PROTECTED]> wrote:John D. Mitchell wrote: > On 5/23/07, Adam Taft <[EMAIL PROTECTED]> wrote: >> John D. Mitchell wrote: > [...] >> > However, I find them useful for optional stuff for non-GET requests, >> too. >> >> Do you have a use case for this? I'm genuinely curious. > > ?output={html,xhtml,json,etc.} > > It's optional in the sense that it's identifying the same resource but > in different output formats. Right, but that's for a GET request. When are you specifying that for a POST, PUT or DELETE? Again, I'm just trying to understand a use case for query strings in a POST/PUT/DELETE. I can't see it currently. Adam
