flâneur — a map of the web's best reading

REST API date format best practices

criteria.sh · saved by 1 readers

Date and time information is so common in APIs that they can make or break your API's developer experience. Most people have an intuitive concept of dates and times, based on their culture, educational background and life experience. Unfortunately, this natural intuition can bias people towards designing poor APIs that don't scale across use cases, geographies or end users. There is a lot of overly simplistic advice within engineering practice, such as "always normalize dates to UTC" or "always use "ISO 8601". This is good advice for many use cases, but not all. Product management can help engineering understand the API's specific use case in detail so that the team can make informed decisions on how to design the API together. Use cases for date and time information fields usually fall under two broad categories: system dates and dates used by humans. The use case that your field falls into informs how you design it. System dates mark the precise time certain events took place within

Date and time information is so common in APIs that they can make or break your API's developer experience. Most people have an intuitive concept of dates and times, based on their culture, educational background and life experience. Unfortunately, this natural intuition can bias people towards designing poor APIs that don't scale across use cases, geographies or end users. There is a lot of overly simplistic advice within engineering practice, such as "always normalize dates to UTC" or "always use "ISO 8601". This is good advice for many use cases, but not all. Product management can help eng

Explore this link on the map →