There are some things about this post that are just fundamentally wrong if you want to put the word REST in the title… First, how you’re determining what the response body format should be (what the content-type header will be). And second, how you’re confusing the POST/PUT payload with the URI query parameters.
The Request class has a property called “parameters”. This property is set in the parseIncomingParams method following these steps: first, you assign the URI query parameters to the $parameters variable. Then, if it’s a POST or a PUT (well, actually, only if the content-type header is set and is application/json or application/x-www-form-urlencoded), you replace URI query parameters with the values specified by the POST/PUT payload.
URI query parameters should not be overridden by the payload. They are completely independent functionally…
Finally, the format should be determined by the accept* headers. The Accept header specifies a list of media types. application/json, application/xml, text/plain, etc… It also specifies priority using the “q score”. The HTTP spec does a much better job of explaining than I will. But again, format, unless you’re dealing with some type of crippled client, shouldnt be determined this way. It’s not RESTful. Not even a little bit.
I love seeing people write about REST, but it’s hard to watch when the explanations are just plain wrong and at best, confusing.
There are a lot of projects out there that are doing really great things with HTTP. In PHP: Symfony 2, Zend 2, 360i Sonno… Java has some excellent resources as well… JAX-RS specification and the Jersey Framework.