So, in using JSONRequest, I have one qualm with it, especially in it's usefulness as a API debugging tool. One of the errors is exceptional in that you can still get valid JSON even though an exception is thrown... "not ok."
In an API that I am testing, it returns a helpful JSON structure even if the HTTP response code is an error. Many RESTful apis do this. For instance, if the status is 400 Bad Request, the call returns more info as a valid JSON structure to let you know what which parameter or such was incorrect - helpful for debugging. Most XML clients still show the response even with a bad HTTP code. JSONRequest hides the data from you, forcing you to rely on some other tool for getting raw data.
Maybe the error object could have an optional 'data' parameter with the parsed JSON in the case of "no ok" but good response?
As far as returning no data on a non-200 response, it's on purpose. The goal of JSONRequest was to, as strictly as possible, follow Douglas Crockford's proposal. http://json.org/JSONRequest.html.
I belief his rational for this behavior is captured in that page in the security section:
"JSONRequest reveals very little error information. In some cases, the goal of a miscreant is to access the information that can be obtained from an error message. JSONRequest does not return this information to the requesting script. It may provide the information to the user through a log or other mechanism, but not in a form that the script can ordinarily access."
Let me know if you agree with his reasoning, or you feel we've misread.
That's a good reasoning, but I'd like to argue with Douglas' position and say that his reasoning applies to invalid JSON. With my suggestion you'd still validate the data coming in and it would not be included in the response if it was invalid for any of the other reasons.
Examples of harmful situations where the HTTP response is something other than OK would be helpful however in understanding his reasoning.
The specification makes sense when you think of it out of context. However, in context of the world of RESTful APIs returning JSON, the developer tries to be RESTful by returning a non-200 status, but tries to be helpful to the developer by returning more information. Perhaps there is a savvy way to return more detailed error info in an HTTP header instead of the content body, but this is the world we live in. Most developers have gone this route and besides the technique is intuitive to most people.
So, I agree with you that you've done the right thing in implementing the spec, but I just have problems with the spec. :)One option might be to offer an extra method to the JSONRequest object for setDebug(1). In this case, the object wouldn't respond according to spec, but it would still be secure. It seems a small price to pay while giving developers a great tool for writing and debugging their JSON applications.