Wednesday, March 16, 2011

Is JSON validation a best practice?

Is it a best practice to validate JSON?

With both a JSON schema proposal and a JavaScript implementation of a JSON Schema validator, this practice would seem relatively frictionless to implement. So, is it a no-brainer that should be part of any robust application? Or do you employ other preferred strategies to handle bad JSON?

From stackoverflow
  • On the server, validation of data coming from outside is a must.

    In the browser, it is redundant from a security POV, if you can vouch that the JSON is generated by server code you control and that any data it depends on has been validated on the server. Even so it can still be useful for debugging.

    happyappa : How are you validating on the server side? I'm kicking my JSON out from PL/SQL, sending it back to a receiving DOJO component. I could see by the JSON references above how to do the validation on the client side...but the server side isn't as clear.
    moonshadow : I mean validate on the server data received from the outside world. If you're bothering to marshall it as JSON in that direction. I'm thinking here of security; for debugging data flowing the other way, validation in the client is good enough. Unhelpfully, I roll my own validation code, I'm afraid.
  • My 2c on this is that:

    (a) Yes, obviously incoming data should be validated, but

    (b) The best place to do this is NOT with Json data as is, but with actual business logic objects, iff data binding is used. JSON validation makes only sense if you handle "raw" JSON, but most services (at least in Java) use data binding first and then operate on biz logic objects, not on data format (which often is almost an implementation detail)

  • I would recommend inclusion of json validation as part of a service perimeter solution. This pattern is described at


Post a Comment