5 ms·

I was actually stopping myself from editing my comment and extending that sentence :) You are right, epoch has some drawbacks. But if you care about any of them

by onli 10y ago

I was actually stopping myself from editing my comment and extending that sentence :) You are right, epoch has some drawbacks. But if you care about any of them, there are a number of different string formats you can use instead. Just save the date as string in iso8601 format. That you can later parse in every language. > JSON fails at being a serialization format because you still have to ask the other side how it "expects to see" binaries represented, or dates represented. That's not a failure, it is a feature. The moment you store binary stuff you always have to communicate with the other side about what exactly is represented and how. JSON does not make false promises. It stores a few main data types and a structure, and that's it. This is the whole "Just use a string" vs "We need to have data types for everything". People who like Unix vs people who like PowerShell, dynamic vs static typing, hackers vs business types. It's a philosophy thing, not a "this is the right way" (apart from mine, obviously).

derefr 10y ago
JSON is (heavily used by people as) an OSI layer 6 encoding—a "presentation layer." Other examples of presentation-layer encodings: ASN.1's encodings [DER, XER]; YAML; the Erlang External Term Format. These encodings take a set of native types, and represent them with canonical encoded/serialized forms. They don't have to allow for faithful bijective encoding of application or domain types (although YAML does), but they are expected to be able to represent any reasonably-common "part of the runtime" scalar or container-ADT type which you might want to use to build your domain types out of. Presentation-layer protocols are the basis of RPC-like protocols like REST or SOAP: you define an application-level message encoding to give semantic meaning (i.e. an application-level type) to terms which have passed through an RPC channel, where those terms arrive in your runtime after RPC decoding with types guaranteed by the presentation-layer protocol you've chosen. JSON is very limited as a presentation-layer protocol, because it guarantees representations for very few types, and many types that are needed to effectively implement RPC-like protocols are not in that small set. This is recognized by some, as there have been a good few attempts to define a presentation-layer encoding "on top of" JSON rather than just using JSON itself... but almost everybody ignores these [fine] layer-6 encodings in favor of continuing to create "JSON APIs" (i.e. layer-7 protocols that specify JSON itself as their layer-6 carrier.) The creators of these JSON APIs then find themselves forced to specify how their particular API represents {binaries, datetimes, sets, strict maps, exceptions, UUIDs, ...}—in other words, to define their own one-off layer-6 encoding atop JSON. And the authors of clients for these APIs find themselves forced to write their own logic to parse and generate representations fitting these specifications—even though they're almost always exactly the same choices as every other API creator made. Choosing a different, richer layer-6 encoding allows both the API creator, and the client authors, to just avoid all that work. Instead, the people who write tooling conforming to the standard for each runtime will do that work, once, and all the API designers and API-client implementors get to benefit by relying on that tooling. Which is rather the point of a standard.
- dragonwriter 10y ago
  > Presentation-layer protocols are the basis of RPC-like protocols like REST or SOAP A nitpick, but, REST isn't RPC-like, and is an architectural style, not a protocol.
  - derefr 10y ago
    Right, I was trying to think how to phrase that, but I couldn't come up with anything better. There's a sort of de-facto layer-6 protocol in the way people use REST in combination with JSON [usually using AJAX calls in browser SPAs] to do RPC, by PUTing or POSTing JSON documents to REST endpoints, and then reading back JSON response bodies. It's a "protocol" where HTTP is doing some of the presentation-layer type-encoding, the "application/x-www-form-urlencoded" encoder is doing some more (for e.g. GET query parameters), and JSON is doing the rest. The "browser-like JSON over REST" RPC approach is so common that it's nearly synonymous with "REST." If you say "we've created a RESTful API", you usually mean that you've defined a layer-7 protocol where browsers use AJAX to make JSON-bodied requests to a hierarchy of REST-architected endpoints, expecting JSON-bodied responses. (There's also JSON-RPC, which a clearer example of a standalone layer-6 protocol with the same problems, but it's not in wide-enough use to really matter.)
vram22 10y ago
Upvoted for that last sentence :)

by onli 10y ago

derefr 10y ago

JSON is (heavily used by people as) an OSI layer 6 encoding—a "presentation layer." Other examples of presentation-layer encodings: ASN.1's encodings [DER, XER]; YAML; the Erlang External Term Format. These encodings take a set of native types, and represent them with canonical encoded/serialized forms. They don't have to allow for faithful bijective encoding of application or domain types (although YAML does), but they are expected to be able to represent any reasonably-common "part of the runtime" scalar or container-ADT type which you might want to use to build your domain types out of. Presentation-layer protocols are the basis of RPC-like protocols like REST or SOAP: you define an application-level message encoding to give semantic meaning (i.e. an application-level type) to terms which have passed through an RPC channel, where those terms arrive in your runtime after RPC decoding with types guaranteed by the presentation-layer protocol you've chosen. JSON is very limited as a presentation-layer protocol, because it guarantees representations for very few types, and many types that are needed to effectively implement RPC-like protocols are not in that small set. This is recognized by some, as there have been a good few attempts to define a presentation-layer encoding "on top of" JSON rather than just using JSON itself... but almost everybody ignores these [fine] layer-6 encodings in favor of continuing to create "JSON APIs" (i.e. layer-7 protocols that specify JSON itself as their layer-6 carrier.) The creators of these JSON APIs then find themselves forced to specify how their particular API represents {binaries, datetimes, sets, strict maps, exceptions, UUIDs, ...}—in other words, to define their own one-off layer-6 encoding atop JSON. And the authors of clients for these APIs find themselves forced to write their own logic to parse and generate representations fitting these specifications—even though they're almost always exactly the same choices as every other API creator made. Choosing a different, richer layer-6 encoding allows both the API creator, and the client authors, to just avoid all that work. Instead, the people who write tooling conforming to the standard for each runtime will do that work, once, and all the API designers and API-client implementors get to benefit by relying on that tooling. Which is rather the point of a standard.

dragonwriter 10y ago
> Presentation-layer protocols are the basis of RPC-like protocols like REST or SOAP A nitpick, but, REST isn't RPC-like, and is an architectural style, not a protocol.
- derefr 10y ago
  Right, I was trying to think how to phrase that, but I couldn't come up with anything better. There's a sort of de-facto layer-6 protocol in the way people use REST in combination with JSON [usually using AJAX calls in browser SPAs] to do RPC, by PUTing or POSTing JSON documents to REST endpoints, and then reading back JSON response bodies. It's a "protocol" where HTTP is doing some of the presentation-layer type-encoding, the "application/x-www-form-urlencoded" encoder is doing some more (for e.g. GET query parameters), and JSON is doing the rest. The "browser-like JSON over REST" RPC approach is so common that it's nearly synonymous with "REST." If you say "we've created a RESTful API", you usually mean that you've defined a layer-7 protocol where browsers use AJAX to make JSON-bodied requests to a hierarchy of REST-architected endpoints, expecting JSON-bodied responses. (There's also JSON-RPC, which a clearer example of a standalone layer-6 protocol with the same problems, but it's not in wide-enough use to really matter.)

vram22 10y ago

Upvoted for that last sentence :)