You can do everything the REST guides tell you, and your API can still break in production.
I’ve built APIs for small startups and for big companies. I’ve seen this happen more than once.
I’ve seen PUT wipe out fields that no client touched. I’ve seen a retry turn one payment into two. I’ve even seen perfectly valid UTC timestamps show hotel guests the wrong check-in time.
Nobody on those teams was careless. They followed good rules. They just used them in places those rules were never meant for.
So use UTC for moments only. For the check-in date, just send the date. For the time, send 15:00 plus the hotel's time zone.
I have to disagree here. Every date and/or datetime should be stored as a datetime. Usually that's UTC but it is appropriate to store it in a location's timezone. Dates are just unspecific windows of time. Nothing ever really happens on a day…
Great API design is about more than following popular conventions; it’s about making systems predictable, secure, and easy to maintain. Practices that seem convenient at first can create compatibility issues and unnecessary complexity as a project…
