Hacker News Reader

Comment by prodigal_erik | Hacker News Reader

If you don't validate JSON, you need yet another massive unit test suite that covers what your app does when it receives various forms of nonsense from someone else. And you aren't going to enforce exactly the same rules as anyone else, so the answer to the question "will this message work?" will inevitably be "it depends, who are you sending it to?" Every protocol change will bring unpredictable interoperability problems.

View on HN

Need is the wrong word there.

The vast majority of json out there is not used for implementing someone else's protocol. So most of us don't need that test suite, we're expecting people to conform to our api, not the other way around.

And how does the schema help in that case anyway? Either the request is according to protocol or not. Your api implements that protocol correctly or not.

And if you need to support different versions of the protocol, just provide different end points, api.v2.mydomain.com, api.v3.mydomain.com.

To make this discussion more concrete, imagine that you have an API that accepts a JSON blob over HTTP/POST.

The blob is expected to be something like:

  {
    "name": "bob",
    "age": 42
  }

Your code needs to handle the case where the fields aren't there, or they have invalid values (eg the wrong type, or a negative age).

You at least need to ignore this input, but if you want this to be a nice API to work with, you probably also want to return error messages that explain what the client did wrong.

You can hand-code this logic (please excuse the pseudo-code):

  if (!input.hasKey("name"))
    print "The 'name' key is required."

  if (typeof input["name"] != "string")
    print("The 'name' key is the wrong type. Expected 'string' " +
          "but got %s" % typeof input["name"])

  if (!input.hasKey("age"))
    ...

... but I think it's clear that this quickly gets tedious and error-prone. JSON schema is one possible solution:

  // schema
  {
    "type": "object",
    "properties": {
      "name": { "type": "string", "minLength": 1 },
      "age": { "type": "integer", "minimum": 0 }
    }
  }

  // handler
  validator = new JSONSchemaValidator(schema)
  if (validator.validate(instance))
    // handle the request
  else
    print validator.errors.join("\n")

XML and XML Schema? All the tools exist and the standards exist! All the tools and specs are also quite good and mature, no need to fix what isn't broken IMHO.

Second to the fact that JSON is more compact than XML, I think people like JSON because it's also more readable; I do envy that to some degree but the expressiveness and universal(ness) of XML shouldn't be ignored! On top of that, you aren't only limited to XML - you can serve data from your API in vocabularies specific to the domain.

JSON's minimalism does have some appeal. All you will ever have to deal with are null, booleans, doubles, strings, arrays, and maps. With XML, you can start with an equally simple RPC format but get pressured into dealing with recurring elements, attributes, whitespace normalization, mixed content, processing instructions, and general entity references, just because they exist as possibilities and (most) parsers support them all.

Oh I don't know, I enjoy tracking down obscure bugs from badly formatted data sent by a client system using a JSON API that I changed 6 months ago.

</sarcasm>

I wholeheartedly agree; introducing schemas is obviously a benefit to JSON. Schemas make things more predictable and plus, nobody's forcing you to use one.

Reply on news.ycombinator.com