If you represent something, you need to interpret it later... i.e. both client and server need the same interpretation in order to avoid errors.
> Dates can be encoded as strings and so can most of the other more 'awkward' types.
You say 'encoding', I say 'serialization'.
> It's not that complicated
It isn't as long as you use the same platform for encoding and decoding.
Maybe our experiences are different. I remember one time I had to unencrypt a string in Ruby that had been encrypted in Java. I thought, this will be simple, it's a standard AES encryption, I'll just stuff the string into the corresponding Ruby object and decrypt! I mean, both of these objects were implemented according to the same industry standard right? Boy was that a learning experience. :) Framing, padding and seeding was not implemented the same way -- it was left as a platform implementation detail that only someone trying to integrate across systems would ever notice.
If you represent something, you need to interpret it later... i.e. both client and server need the same interpretation in order to avoid errors.
> Dates can be encoded as strings and so can most of the other more 'awkward' types.
You say 'encoding', I say 'serialization'.
> It's not that complicated
It isn't as long as you use the same platform for encoding and decoding.
Maybe our experiences are different. I remember one time I had to unencrypt a string in Ruby that had been encrypted in Java. I thought, this will be simple, it's a standard AES encryption, I'll just stuff the string into the corresponding Ruby object and decrypt! I mean, both of these objects were implemented according to the same industry standard right? Boy was that a learning experience. :) Framing, padding and seeding was not implemented the same way -- it was left as a platform implementation detail that only someone trying to integrate across systems would ever notice.