Part 1 of this series examined how handling date and time presents a slightly different challenge than other data types. Part 2 focused on design-time considerations, including schema, validation, and operation definitions. In Part 3, we will look at some of the implementation aspects, and I will use javascript as the language here. Accepting date-time If you are building an API, enforce a standard format. I generally use ISO 8601 for date, time, and timestamps....
Part 1 highlighted the complexity of handling date and time. Part 2 focuses on design-time considerations, including schema, validation, and defining operations. I have been part of multiple teams where we had to design data schemas. When it came to storing date and time, we just slapped on the ISO 8601 format (which, if you ask me, is the only format you would ever need). ISO 8601 format has date, time, and timezone information....
First, let’s talk about the basics. We all know the usual data types – strings, numbers, and booleans. They’re like the bread and butter of programming. Databases and programming languages have matured to the point where they can safely handle these data types, and we don’t think twice about how we store, retrieve and perform operations on them. They know that we know that there are a set of expectations, and it should work....
From Single-Document Updates to Multiple-Document Mayhem When creating or supporting HTTP APIs for database operations, the technique is to connect HTTP methods to database operations. The widely accepted mapping is as follows: GET: Find POST : Insert/Create PUT: Update DELETE: Delete/Remove (Unless you’ve adopted GraphQL, in which case, what in Middle-earth?!) In general, everyone agrees on how POST, GET, and DELETE operations are supposed to behave. There isn’t much room for ambiguity there....