4 ms·

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 solve

by kennu 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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 16y ago
        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.
- strebler 16y ago
  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.

by kennu 16y ago

prodigal_erik 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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.
strebler 16y ago
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.