Throw your support behind https://json-schema.org it's a great effort.

Or use something sane like protocol buffers

I've used protobufs in the past and I REALLY want to use them now, but the human readable aspect of json has always kept me coming back.

If I want to perform some rough tests of an endpoint during development, all I need to do is compose the json request and fire it off using curl. The response then comes back in a human readable format I can parse straight from the terminal. Boom, simple test conducted in less than 1 minute. I don't even need to think about it.

Compare that to protobufs; I need to create a custom client or unit test that'll compose and fire off the request I want to test, then I need to write a bunch of code that will introspect the contents of the response so I can pick out the details. Huge time loss, concentration ruined since I need to actually think about the process, I'd rather just take the extra latency that using json will incur.

This skips past all of the other advantages json has over binary serialization protocols, like quickly being able to parse requests while debugging issues, infinite client language support, ease of sharing breaking requests to help devs reproduce problems, not needing to add an extra compilation step to my deployments and packages, etc.

> If I want to perform some rough tests of an endpoint during development, all I need to do is compose the json request and fire it off using curl. The response then comes back in a human readable format I can parse straight from the terminal. Boom, simple test conducted in less than 1 minute. I don't even need to think about it.

https://github.com/fullstorydev/grpcurl

A problem we're finding with those is the massive runtime dependency you get trying to include protobuf in browser.

In that case json can be used as an addon. An optional input/output that a number of protobuff libraries support.

One should keep schema in protocol buffers and encourage its use for all but browsers.

The minimal parser seems to be 6.5kb, which seems significantly smaller than most of other JS dependencies apps use these days.

We make dependencies, so staying small is more important for us than for end-users.

Protobuf crashes with data larger than 2GB (json does not).

This severely limits its usefulness, unless you want to put workarounds of this shortcoming into your application.

Other protobuf-like things like capnproto don't have that restriction, because they don't use 32 bit integers for sizes.

You really don't want to put >2GB in a single protobuf (or JSON object). That would imply that in order to extract any one bit of data in that 2GB, you have to parse the entire 2GB. If you have that much data, you want to break it up into smaller chunks and put them in a database or at least a RecordIO.

Cap'n Proto is different, since it's zero-copy and random-access. You can in fact read one bit of data out of a large file in O(1) time by mmap()ing it and using the data structure in-place.

Hence, it makes sense for Cap'n Proto to support much larger messages, but it never made sense for Protobuf to try.

Incidentally the 32-bit limitation on Protobuf is an implementation issue, not fundamental to the format. It's likely some Protobuf implementations do not have this limitation.

(Disclosure: I'm the author of Protobuf v2 and Cap'n Proto.)

Generally speaking, if you have 2GB of data, why would you want it inside a protobuf, or worse, json? You clearly aren't going to open it in a text editor or send it over ajax - just put the bulk of data as a separate binary blob, and your code won't have to scan 2GB to find the end of a string.

Not even remotely is it a severe restriction. Very few need that.

While it’s a valid point, there are many workarounds.

Also even in json, splitting documents in smaller chunks (ndjson for instance) is the standard practice to avoid having to parse it all in one go.

How would I pad my resume if I didn't keep reinventing the same wheels over and over?

I can understand if protocol buffers had some technical issue that you disagreed with. Or if you had a preference for a different solution because of some reason.

But this comment seems needlessly cynical and doesn't actually offer any rebuttal to the parent's point. I find technical discussions of these sorts of things interesting and a great way for new people to learn about the tradeoffs, maybe you could offer a reasoned opinion on why not use protocol buffers?

I think GP is making fun of people who do not use protobufs and instead try newer, less proven ones...

I have a love/hate relationship with JSON schema. I hate the documentation, or significant lack thereof. But I do love how business rules about relationships between fields can be expressed in the schema - e.g., if typeId is 7, then the cost field must be populated.

With things like Avro or GPB you still need to validate that the relationship holds true separately.

Isn't that just lipstick on a pig? Why not use something pre-existing and well defined?

What is your opinion of the swagger spec + definition?

A lot of companies still use typed messages like Protocol Buffers which make this a signficantly smaller issue. Especially since the message format was designed to be portable.

A question: just like JSON's syntax was based on JavaScript, could we create a JSON schema syntax based on TypeScript? So the schema would essentially be a TypeScript type annotation.

JSON schema validation requires a JSON parser so not sure how this helps in the context.