4 ms·

When have you ever written a program that doesn't know ahead of time what type of data it's going to be operating on? Especially if you're using a statically t

When have you ever written a program that doesn't know ahead of time what type of data it's going to be operating on? Especially if you're using a statically typed language. Whether you validate incoming payloads in JSONSchema or not, you will always have some understanding of what the shape of the incoming JSON is supposed to be, down to the most concrete types. You'll probably receive many JSON payloads that all conform to the same schema. So why bother redundantly describing that schema in every individual payload? If you want strict types, write a JSONSchema. If you need to know specific sub-type information, start specifying what should go into the "format" field in JSONSchema. They did it in Swagger: http://swagger.io/specification/ http://swagger.io/specification/ Since the article complains about JSON parsers not knowing how to handle certain situations, perhaps people should start writing JSON parsers that allow you to pass in a JSONSchema document at parse time so they're sure to handle each field type correctly.

3pt14159 10y ago
Plenty of times, either when I'm taking other people's JSON or when I'm coding for future-me or for arbitrary JSON traversal or search. But I agree that TJSON rubs me the wrong way. The simplicity of JSON is what I like and I can code around it when I need to.
- dvdhnt 10y ago
  ^ this
lobster_johnson 10y ago
There are many use cases where you don't know the shape of the data. Many apps need to index or store or transform arbitrary key/value pairs, but without knowing anything about those keys or values mean. JSON is a schemaless interchange format, so those situations arise pretty much by default. Not that I love this format -- fixing JSON needs a bit more effort, especially on syntax.
- colanderman 10y ago
  > Many apps need to index or store or transform arbitrary key/value pairs, but without knowing anything about those keys or values mean. Then those apps shouldn't be interpreting those values. E.g. if you don't know and don't care whether a given JSON number is an integer or a decimal, don't represent it as a number in your app. Just copy the serialized number verbatim (or a canonicalized version thereof).
  - lobster_johnson 10y ago
    Of course, if you're not touching it, that's a fine strategy. But maybe you're transforming it. Or you want to parse it, extract some value and send it somewhere. There are lots of use cases where there's no way around parsing and interpreting the data types in a JSON blob.
    - colanderman 10y ago
      I don't mean the entire JSON structure. Go ahead and parse that; leave the individual values opaque.
bascule 10y ago
The zen of JSON is it's a schema-free, self-describing structure. If people can be bothered to deal with schemas, they can probably also consume the Protobuf serialization of a particular object. JSON is targeting a market that doesn't want to do that. There's no reason such an audience can't also reap the benefits of richer types and cryptographic authentication. TJSON aims to provide these benefits to programmers who don't necessarily want to consume schemas up-front to integrate. This is particularly useful for tools which consume a small number of fields. There's a lot of overhead to pulling in IDL definitions (and keeping them up-to-date), and often it's coupled to boilerplate code generation systems. If you're just plucking a few fields from an object here and there, there's no need to go through that ceremony. I say this as someone who's defining the data model in Protobufs. If you're doing any serious data access / API integration: use protobufs. But JSON is a nice fallback for simpler integrations. That is quite literally the point of going through this whole exercise.

3pt14159 10y ago

Plenty of times, either when I'm taking other people's JSON or when I'm coding for future-me or for arbitrary JSON traversal or search. But I agree that TJSON rubs me the wrong way. The simplicity of JSON is what I like and I can code around it when I need to.

dvdhnt 10y ago
^ this

lobster_johnson 10y ago

There are many use cases where you don't know the shape of the data. Many apps need to index or store or transform arbitrary key/value pairs, but without knowing anything about those keys or values mean. JSON is a schemaless interchange format, so those situations arise pretty much by default. Not that I love this format -- fixing JSON needs a bit more effort, especially on syntax.

colanderman 10y ago
> Many apps need to index or store or transform arbitrary key/value pairs, but without knowing anything about those keys or values mean. Then those apps shouldn't be interpreting those values. E.g. if you don't know and don't care whether a given JSON number is an integer or a decimal, don't represent it as a number in your app. Just copy the serialized number verbatim (or a canonicalized version thereof).
- lobster_johnson 10y ago
  Of course, if you're not touching it, that's a fine strategy. But maybe you're transforming it. Or you want to parse it, extract some value and send it somewhere. There are lots of use cases where there's no way around parsing and interpreting the data types in a JSON blob.
  - colanderman 10y ago
    I don't mean the entire JSON structure. Go ahead and parse that; leave the individual values opaque.

bascule 10y ago

The zen of JSON is it's a schema-free, self-describing structure. If people can be bothered to deal with schemas, they can probably also consume the Protobuf serialization of a particular object. JSON is targeting a market that doesn't want to do that. There's no reason such an audience can't also reap the benefits of richer types and cryptographic authentication. TJSON aims to provide these benefits to programmers who don't necessarily want to consume schemas up-front to integrate. This is particularly useful for tools which consume a small number of fields. There's a lot of overhead to pulling in IDL definitions (and keeping them up-to-date), and often it's coupled to boilerplate code generation systems. If you're just plucking a few fields from an object here and there, there's no need to go through that ceremony. I say this as someone who's defining the data model in Protobufs. If you're doing any serious data access / API integration: use protobufs. But JSON is a nice fallback for simpler integrations. That is quite literally the point of going through this whole exercise.