Lessons of JSON

http://inkdroid.org/journal/2012/04/30/lessons-of-json/

by bpierre • 14 years ago

97 32 14 years ago

inkdroid.org

nolok2• 14 years ago

JSON and SOAP, the two PR guys for KISS

jerf• 14 years ago

I assume by that you mean that SOAP is a PR guy for KISS by virtue of showing what happens when you don't?

nolok2• 14 years ago

Yes

olavk7• 14 years ago

KISS is not a magic formula, though. The precursor to SOAP was XML-RPC which is very simple. So simple it didn't allow time zones in datetimes, and didn't support characters beyond ASCII in strings. There was no way to extend XML-RPC to support unicode or unambigous datetimes. This basically killed XML-RPC for most of the world. JSON already have problems because there is no datetime format. People need datetimes, so several incompatible hacks have been designed to represent datetimes as strings. There is no way to extend JSON to support proper datetimes.

The complexities in SOAP are there because someone need it. Someone already have invented a schema language for JSON: http://json-schema.org/. If every feature from the SOAP stack is reinvented for JSON, JSON will end up as complex as SOAP. Then someone else will surely invent yet a new standard (web-sexprs?) and claim it saves us from the needless complexity of the JSON-stack.

The bottom line: Some systems have simple needs, some systems have complex needs. Making a format layered and extensible (like the SOAP-stack) introduces additional complexity. But a non-extensible format requires complex hacks if your needs grows beyond what the format were design for. There is no perfect one-size-fits-all data format.

RyanMcGreal2• 14 years ago

The important thing to remember is that sometimes the solution to a problem adds so much overhead that it actually creates a bigger problem than the problem it solved. That has been the fate of SOAP, at least for the vast majority of uses.

mkramlich• 14 years ago

That reminds me of that saying I heard about XML:

"Some people have a problem and think they can solve it with XML. Then they have two problems."

knewter• 14 years ago

FWIW, I'm using json-schema in a project and find it both fantastic and lightweight, and it feels not at all like I'm tending towards SOAP. YMMV

Cloven• 14 years ago

datetime is a data format problem, not a data structure format problem.

icebraining• 14 years ago

Agreed; defining that stuff is up to an higher layer - we just need to make a standard for that too.

JSON-LD, for example, has typed datetimes, links, etc: http://json-ld.org/

pixelcort• 14 years ago

The other limitation of JSON is there doesn't appear to be a standard way of representing Unicode code points above 16 bits (such as some Emoji) in strings. One way I've seen it done is to put two escaped UTF-16 surrogate pairs together; another way I've seen it done is having the UTF-8 literal inside the string.

sopooneo• 14 years ago

Please forgive my ignorance, but why not? Couldn't the entire JSON response be, for instance, UTF-8 encoded, thus allowing the representation of all possible Unicode code points?

olavk7• 14 years ago

Apparently the first solution is the correct according to the RFC: http://www.ietf.org/rfc/rfc4627.txt

To escape an extended character that is not in the Basic Multilingual Plane, the character is represented as a twelve-character sequence, encoding the UTF-16 surrogate pair.

This is regardless of whether the json itself is UTF-8 or UTF-16 encoded.

function_seven• 14 years ago

I'm still wet behind the ears when it comes to Unicode, but why can't the character just be transmitted "natively"? (Like you said, UTF-8 inside the string assuming the encoding is set to utf8) {"I'm unicode" : "←"}

clarkevans• 14 years ago

Fundamentally, XML has the wrong information model for most applications -- it is a document markup language often used as a data serialization format. SOAP inherits quite a bit of this complexity, irrelevant to the task of data serialization. Even if all of the necessary features from SOAP are layered on top of JSON, the result would be less complex than SOAP.

olavk7• 14 years ago

Unless of course you actually want to transmit structured document content over JSON - which is actually pretty common in AJAX applications.

ender7• 14 years ago

Why not just use Unix time (in milliseconds) for your timestamps? You'll have to convert it to whatever your desired container format is on the other end of the wire, but...you're going to have to do that for all of your other data as well.

ominous_prime2• 14 years ago

It would be ambiguous, since you need to know what timezone the timestamp is from. This is why most applications use ISO8601.

olavk7• 14 years ago

Sure. Or you can use one of the ISO 8601 date formats encoded as a string. Or the special string "\/Date(...)\/" which some JSON libraries have chosen. The problem is not to encode a date, the problem is there is no agreed way to do it, so you can't be sure that the other end actually receive a date.

acdha• 14 years ago

xml-rpc was a classic Winer format and like RSS it shared the same limited interest in cleaning up oversights. Not handling unicode was simply lazy - the support was there in XML so it took effort to disable a native feature. Similarly, date encoding is a solved problem for almost all applications: use ISO 8601.

This is not to say that there are areas where complexity will creep in or that some people haven't learned from the failure of SOAP (or CORBA before it) but simply that for the vast majority of cases the problems just aren't that hard unless we choose to make them hard.

6ren2• 14 years ago

To bring out your implicit point, use the right tool for the job. For a simple job use JSON, for a complex job use XML (and XML schema, XSLT etc). Moreover, the existence of XML keeps JSON simple.

Instead of complex needs motivating people to complicate JSON with hacks, they just use the XML stack. Complicating proposals for JSON (like json schema) don't get traction, because their would-be users already have their complicated needs met.

And... enough grey-beards are around to make this point. I will add that before XML, there was CORBA. XML was hailed as simpler, til people added all the bits that were missing. In the bigger picture, I think everyone is waiting for a replacement for the XML stack that really is genuinely simpler - not just reinventing the same hacks on a different base.

olavk7• 14 years ago

I am skeptical it is possible to invent a stack which solves the same set of problems as SOAP but is significantly simpler. (I would love to be proven wrong though!)

telent• 14 years ago

The lack of a timestap datatype is a problem, but the lack of a 'link' datatype is imo a greater one, now that people are doing supposedly-RESTful APIs with JSON payload. Which is not to say that you can't layer that type info on top of JSON (see e.g. HAL) but you do need both ends to agree that that's what you're doing otherwise it kind of treads on the "no out-of-band info" property

6ren2• 14 years ago

> Rather than claiming he invented JSON he instead says he discovered it–almost as if he was a naturalist on an expedition in some uncharted territory.

JSON is part of javascript (it's even right there in the name). Far from uncharted territory, javascript was a deliberate human creation. His contribution was to extract that specific part, and apply it to another problem.

Lessons of JSON

Related Stories