3 ms·

Without a strongly-typed data exchange format, you constantly have to write code that makes assumptions you hope the sender followed. Timestamps are ISO formatt

Without a strongly-typed data exchange format, you constantly have to write code that makes assumptions you hope the sender followed. Timestamps are ISO formatted. No, timestamps are seconds since 1970. No, they're floats including milliseconds. Blobs are base64. No, hex. Money is a string. No, it's a float. No, it's an int in micros. An empty array is different than an omitted field. No, they're the same. No, multiple values are comma-delimited strings.

creshal 11y ago
> Money is a string. No, it's a float. No, it's an int in micros No, it's a decimal number with attribute-dependant accuracy settings, with at least three different accuracy levels used in the same object used for different purposes. (Just something I came across today at work. Thankfully, my SOAP library handles that automatically…)
dec0dedab0de 11y ago
But no matter what format any bit of data is in, it should still be documented. Then any consumers of the data are going to have to convert it into a format that suits their language and application.
- wtbob 11y ago
  > But no matter what format any bit of data is in, it should still be documented. That's what types are: enforced documentation.
  - dec0dedab0de 11y ago
    That's what types are: enforced documentation. That's an interesting way to think about it, but I'm not sure it applies here. From the example given about money being a string or a float. A type would just enforce either or, but the consumer of the data would still need to know what it is, and convert it to whatever is necessary for them.