Back to Feature Ideas Forum
0

have JSON Request return data on error "not ok"

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?

{name:"JSONRequestError", message:"not ok" data: {object} }

For an example API you should be able to use JSON output from either the Upcoming or Flickr API

by
Report Abuse
2 Replies
  • Hey Skylar!

    Welcome and thanks for postin'.

    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.

    nice to have you around :)lloyd
    Report Abuse
    0
  • 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.
    Report Abuse
    0
✕ This forum is locked.
Ask a Question

Recent Posts

in Feature Ideas