“URI query parameters should not be overridden by the payload. They are completely independent functionally…”

That part is correct. Lorna should not be overwriting any of the query params she parsed with data from the payload (and she is using parse_str() on REQUEST_URI, which makes no sense, since she could simply use $_GET for this purpose).

The rest of your comment is nonsense:

1) The Content-Type header of a request (and parsing a request is what this article is about) is used by the *client* to tell the *server* what format the data in the request body is in. So if I, as a client, POST or PUT some JSON to a URI, I must (well, should as per the HTTP spec) include a Content-Type: application/json header so the server can parse the entity body enclosed in the request and does not have to resort to sniffing. You are confusing this with the other use for a Content-Type header, where a server sends it along with a response to indicate to the client what the type of the payload is.

2) The Accept header is used by a client to indicate his preferred response format(s) to a server. The server may or may not follow this (it’s perfectly adequate for a server to send a response in a format not indicated in the Accept header, clients must be able to deal with this situation)

3) You say “It’s not RESTful. Not even a little bit.” without elaborating much, but it seems to refer to the use of Accept (or Content-Type?) headers to perform content negotiation. Given how the identification of resources through URIs and the representation of resources through different media types are conceptually separate in REST (please read Fielding’s dissertation), I need to conclude that you don’t know what you’re talking about.

All this, however, is really just about HTTP in the end, and not about REST, which so far has not been addressed in this series of posts (but we’re only one article in), because RESTful interfaces must use Hypermedia formats (and application/json is not one and neither is application/xml, since they both have no attached semantics) to implement something called “Hypermedia As The Engine Of Application State”, also called “HATEOAS” or “the most important thing about REST that most people ignore or just plain do not understand”. If you don’t believe me, believe The Roy: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

That, then, would be my main criticism of this article, no mention of Hypermedia, but there’s two more articles to go apparently, so I’ll spare judgement until the end.

Other feedback: parsing JSON into parameters might not be a good idea, since ultimately, the request should be handled like a document, not like a set of keys and values, if the server wants to handle unknown fields in a non-destructive manner (and it precludes the support of an XML based media type since you cannot map elements with attributes in a similar manner). HTML forms really have a whole range of edge cases that make them rather special; I’d start out purely with JSON and/or XML and go from there. The code of course could also simply be $parameters = array_merge($_GET, json_decode($body, true));, and again, if it’s urlencoded form data, why not just use $_POST instead of parsing stuff by hand?