Send numbers as strings. you should be treating this as hostile in your backend anyways, and checking it.
Send both an error code, and a string in simple english, or whatever your most common developer language is.
If you care about only updating certain fields, track changes and only send those fields to the backend.
These arn't really that hard.
In other news we’re suspecting transactions are on horizon. Half the backend team are in denial, the other half are busy trying to figure out the most pleasant place to install decidedly “unRESTy URLs” for them. Somebody already set themselves on fire over PUT/POST for that.
With offset, ok. As UTC alone, it doesn't work if you need to know the local time when something occurred, like medication administration, especially when the things may occur across time changes like DST.
The endpoint of the viewer may not be in the same local time.
If you go this route you may not care about location beyond this one data point, but have to store another location field each time.
Why? Why not send a number as number (double) and treat it as hostile in the backend? I dislike sending numbers as string because I think the different data types exist for a reason.
Same thing with serial numbers, VIN numbers, building floor numbers, phone numbers, etc. All of those should always be strings, because performing "math" on them wouldn't yield meaningful results.
Why should i send a dimension as a string? How am I going to calculate the volume from 3 strings?
You shouldn't because a dimension is a number. Something 4 feet long is twice as long as something 2 feet long.
So prices are numbers (if supplied in cents, the smallest unit). There is length/depth/height/weight/... A lot of things are actual numbers. Why supply them as string?
I agree partially with you but think ZIP are a very bad example because a zip itself may also contain letters.
Either that or use a different serialization method to communicate.
No one else seems to be complaining about this issue. If JSON doesn't fit your needs, use something else.
what's an ISO date/time?
> JSON.stringify(new Date())
'"2021-02-22T20:34:53.686Z"'That said, "time zone designator" is the formal name of the UTC offset in ISO 8601, and it's reasonable to refer to it as such whenever the distinction is clear.
Handling Post and Patch differently can at least give a general guideline for "overwriting vs keeping fields on update."
The localisation part is trivial if you consider that APIs are to be consumed by machines - much harder, if you assume they're used for GUIs.
Error handling is easy to define right, but so tedious to implement....
1+n can be improved by "guessing" which nested ressources are going to be fetched, and include them "by default."
But you're right that those are decisions that need to me made, and can quickly be agonised on without adding much value....
This distinction is important because you can't serialize infinities or NaN, and there's no guarantee the JSON number can be accurately represented as a double. JS likes to pretend that JSON number is interchangeable with Number and this can result in some fun situations when your Infinity becomes null
I guess the point is that JSON has about as much to do with JS as JavaScript has to do with Java.
- How to handle date and time incl. time zones - JSON has no data type for that - Handling of numbers (JSON only has double, which does not fit most cases) - Defined and parseable error responses (rfc 7807 plus extra fields for details) - Localization - do you send translated texts or just error codes? - How to handle updates? Overwrite every field? How to update only some fields for a resource? Optimistic locking? - How to handle 1+n problems for reading? ...