Lessons of JSON

#1

Post by bpierre » Mon, Apr 30, 2012, 1:59 PM UTC

Lessons of JSON
inkdroid.org

Re: Lessons of JSON

#2

Post by nolok » Mon, Apr 30, 2012, 3:25 PM UTC

JSON and SOAP, the two PR guys for KISS

Re: Lessons of JSON

#3

Post by treddy » Mon, Apr 30, 2012, 3:35 PM UTC

what are the use cases JSON don't solve?

Re: Lessons of JSON

#4

Post by neckpunch » Mon, Apr 30, 2012, 3:43 PM UTC

JSON was refreshing when it emerged because it didn't try to build a protocol on top of already functional protocols.

All the Java-and-XML-Land SOAP/RPC offerings were way over-engineered for simply moving serialized data around.

I will raise a toast this evening to Crockford and the others who brought us JSON.

Re: Lessons of JSON

#5

Post by jerf » Mon, Apr 30, 2012, 4:09 PM UTC

nolok wrote: post #2

JSON and SOAP, the two PR guys for KISS

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

Re: Lessons of JSON

#6

Post by olavk » Mon, Apr 30, 2012, 4:44 PM UTC

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.

Re: Lessons of JSON

#7

Post by RyanMcGreal » Mon, Apr 30, 2012, 4:57 PM UTC

olavk wrote: post #6

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…

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.

Re: Lessons of JSON

#8

Post by knewter » Mon, Apr 30, 2012, 5:00 PM UTC

olavk wrote: post #6

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…

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

Re: Lessons of JSON

#9

Post by Cloven » Mon, Apr 30, 2012, 5:18 PM UTC

olavk wrote: post #6

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…

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

Re: Lessons of JSON

#10

Post by pixelcort » Mon, Apr 30, 2012, 5:22 PM UTC

olavk wrote: post #6

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…

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.