6 ms·
Lessons of JSON
- nolok 15y agoJSON and SOAP, the two PR guys for KISS
- treddy 15y agowhat are the use cases JSON don't solve?
- neckpunch 15y agoJSON 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.
- olavk 15y agoKISS 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/ 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.
- RyanMcGreal 15y agoThe 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 15y agoThat 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."
- RyanMcGreal 15y agoSidenote: that's actually a reference to a usenet post from 1997 by Jamie Zawinsk, a Netscape engineer and the driving force behind the open-sourcing of the Mozilla codebase. In the original, Zawinski was talking about regex: > Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. Zawinski's post, in turn was a reference to a 1988 sigfile from John Myers, quoting D. Tilbrook: > Whenever faced with a problem, some people say "Let's use AWK." Now, they have two problems. You can find a detailed history here: http://regex.info/blog/2006-09-15/247 http://regex.info/blog/2006-09-15/247
- knewter 15y agoFWIW, 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 15y agodatetime is a data format problem, not a data structure format problem.
- icebraining 15y agoAgreed; 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/ http://json-ld.org/
- telent 15y agoThe 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
- 6ren 15y 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.