JSON Validation with JSON Schema | Hacker News Reader

JSON Validation with JSON Schema

davidwalsh.name

28 pointsDanielRibeiro10 comments

I think bringing schemas to JSON is a dangerous road, because they have made XML-based interfaces difficult to expand. Unless there's a real problem to be solved, they just add overhead with having to distribute new schema versions to clients etc.

I much prefer the original JSON approach of adding new fields over time as needed, and letting applications use them or ignore them. Keep it simple.

(Schemas may be more relevant if you try to map the structures to statically typed languages. But the whole point of JSON is that it maps very comfortably to the dynamic array and dictionary structures of dynamically typed languages.)

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.

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.

IMHO, JSON schema goes against the spirit of JSON. Why not just use XML if you need these types of features? XML already has mature schema tooling.

At http://www.webpop.com we're using JSON Schema as the way to define custom content types behind the scenes.

This in combination with MongoDB works really well for us. When a user sets up a custom content type, he's actually setting up a JSON Schema for his content without knowing it. And each time a content is persisted we simply validate it against the schema.

For now it's just an internal implementation detail, but we plan to expose this through a public REST API at some point.

Yes and let's call JSON, XML 2.0?

Reply on news.ycombinator.com