If you subtract out "HTTP can be applied to JSON", what seems to be left is a minor specification of a standardized error JSON object. There's not much "there" there; everything interesting is "left to the server".
Agreed. I was really hoping that the document would get into some best practices around the structure of the JSON objects themselves, particularly in regards to self-documenting, such as:
1. Requiring that the root of the application or domain contain metadata regarding the resources available to the JSON service.
2. Providing a common documentation and structure for nested resources, including perhaps counts and a reference URI for accessing the nested resource, along with an alternate scheme when nested resources are embedded in the resource itself.
3. Documenting how identifiers and references to other resources are included in a JSON object.
4. A standard structure for how collections should be queried (how to reference fields, specify operators, provide values, etc.)
These sorts of concerns are the things in which there's tons of variation and lots of disagreement on standardization. Using HTTP verbs to describe operations in JSON services is well understood and doesn't require much in the way of standardization.
