

JSON Validation with JSON Schema - DanielRibeiro
http://davidwalsh.name/json-validation

======
kennu
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.)

~~~
prodigal_erik
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.

~~~
mattmanser
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.

~~~
aboodman
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")

~~~
Ixiaus
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.

~~~
prodigal_erik
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.

------
rbranson
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.

------
bobfunk
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.

------
kqueue
Yes and let's call JSON, XML 2.0?

