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?
Yes
Lessons of JSON
21–30 of 35 posts
Re: Lessons of JSON
#22Earlier quoted context omitted.
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.
It would be ambiguous, since you need to know what timezone the timestamp is from. This is why most applications use ISO8601.
Unix time is always UTC, isn't it?
Re: Lessons of JSON
#23Earlier quoted context omitted.
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.
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?
Yes. In fact, JSON documents must be Unicode text, and the default encoding is UTF-8.
Re: Lessons of JSON
#24Earlier quoted context omitted.
It would be ambiguous, since you need to know what timezone the timestamp is from. This is why most applications use ISO8601.
Unix time is always UTC, isn't it?
Yeah, it is. I was thinking that since it just a raw number of seconds with no TZ designation, that there's too much room for incorrect implementations using localtime.
Re: Lessons of JSON
#25KISS 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…
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.
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.
Re: Lessons of JSON
#26Earlier quoted context omitted.
Unless of course you actually want to transmit structured document content over JSON - which is actually pretty common in AJAX applications.
In that case, you can use the appropriate XML format for the structured document content, then store than in a JSON string. Most of the time the "structured document content" you're sending over AJAX is HTML or SVG, and the browser can still handle parsing and validating it.
Yeah, and it works fine. But it is hard to argue that JSON+XML is a simpler data interchange format than just XML.
It might be better though, because the JSON and the XML is handled by different layers in the application anyway.
Re: Lessons of JSON
#27Earlier quoted context omitted.
In that case, you can use the appropriate XML format for the structured document content, then store than in a JSON string. Most of the time the "structured document content" you're sending over AJAX is HTML or SVG, and the browser can still handle parsing and validating it.
Yeah, and it works fine. But it is hard to argue that JSON+XML is a simpler data interchange format than just XML. It might be better though, because the JSON and the XML is handled by different layers in the application anyway.
Sure it’s simpler: they’re used in two separate layers – each with its own purpose – which are consumed by separate components (and actually more, because when you send this down you’re of course wrapping it in HTTP and TCP &c.). For a better understanding of why this kind of design is simpler, and therefore better, I recommend Rich Hickey’s talk: http://www.infoq.com/presentations/Simple-Made-Easy
Edit inre “more complex compound data exchange format”: No, the point is that this should be thought of as two simple protocols wrapped one inside the other, not one “complex” format. Watch Rich Hickey’s talk. It would be a complex format if the two layers reached across into each-other, if the consumption of one depended on the details of the other, etc. But if they’re kept properly separate, that’s not complex – by Hickey’s definition anyhow, and I think it’s an excellent definition.
Re: Lessons of JSON
#28The 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
Re: Lessons of JSON
#29Earlier quoted context omitted.
Yeah, and it works fine. But it is hard to argue that JSON+XML is a simpler data interchange format than just XML. It might be better though, because the JSON and the XML is handled by different layers in the application anyway.
Sure it’s simpler: they’re used in two separate layers – each with its own purpose – which are consumed by separate components (and actually more, because when you send this down you’re of course wrapping it in HTTP and TCP &c.). For a better understanding of why this kind of design is simpler, and therefore better, I recommend Rich Hickey’s talk: http://www.infoq.com/presentations/Simple-Made-Easy Edit inre “more co…
Agreed, the overall architecture may become simpler by choosing a more complex compound data exchange format.
Re: Lessons of JSON
#30KISS 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.
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/