While researching a database to use in a project, the team I am working with came upon yet another graph database. Every time I turn around there is a new graph/NoSQL database. How can anyone possibly keep up with these is beyond me, but I try. (Insert shameless plug for my GraphDev Discord server).

Maybe we should make our own database, lol.

Interestingly while theorizing testing and implementation to even begin comparing performance, we decided that we might take an un-traditional approach and fork the open source database written over yet another triple-store, and insert our business logic directly into the database. This was after I jokingly said that maybe we should make our own database.

But we don't want to make a database, we only need an API layer for our application. We already have an API being used in production. We just need to replace the database this API is using to store our data.

So, we went back to discussing how this new database handles API connection and end-user authentication. The API needs a connection to the database to be able to authenticate users, but an authenticated user needs to be able to use an individual connection through the API to the database. But why? One of the deciding factors in using this database is its advanced auditing which is directly attached to the client. We don't need to just audit at our API database connection level but at the end-user/client level.

So what if we instead send additional context through our API of the end-user/client making the mutation and query audit trails based upon this additional information? That might work, but would require again forking the database to change how the audit function runs. If we are then going to fork the database already, then why not just move the other logic from our API into the database too? But would that mean we have built (or forked and extended) a database and no longer have an API?

What is it exactly that distinguishes databases from APIs? According to ChatGPT:

The term "database" generally refers to a structured collection of data that is organized and can be easily accessed, managed, and updated. Qualifications for a project to be termed a database often include the ability to store, retrieve, and manipulate data in a systematic way.

If your project uses a datastore underneath and meets the criteria of a structured collection of data with organized access and management capabilities, you can likely refer to it as a database. However, it's important to consider specific features and functionalities associated with traditional databases, such as support for querying, indexing, transaction management, and data integrity.

Wait, is our API already classified as a database? Our API contains a structured collection of data with:

• ✅ Organized access and
• ✅ Management Capabilities.

Our API also has support on some levels for:

• ✅ Querying,
• ✅ Indexing,
• ✅ Transaction Management, and
• ✅ Data Integrity

So, as any intelligent person would do, I asked ChatGPT for help again, "Can an API layer be called a database?"

No, an API layer typically cannot be called a database. An API (Application Programming Interface) is a set of rules and protocols that allows different software applications to communicate with each other. It facilitates the exchange of data and functionality between different systems.

On the other hand, a database is a structured collection of data that is organized for easy retrieval, update, and management. It provides a mechanism for storing, querying, and manipulating data. While an API can be used to interact with a database, the API itself is not a database.

Umm, so then if this is correct, an API is only a set of rules and protocols to communicate between the layers. Some of these rules entail layer 7 authorization presumably. Reading into this a little deeper, the API exchanges data, while the database stores, queries, and manipulates the data. Ok, then by what right, is the database we are using hold its claim that it is a "database"? The same could be said of most of the "databases" released over the last decade.

The API exchanges data, while the database stores, queries, and manipulates the data.

This was enough circular reasoning to hurt my brain, so after I finished working for the evening and signed off, I checked LinkedIn and for sure they overheard our conversation because there it was again...

...FHIR servers can act like "databases", even though they are not... While normal databases had tools like Database Visualizers, FHIR had nothing but Postman. So Darren built the Vanya FHIR utility... Are FHIR servers acting more and more like databases? Is there a need to build tooling similar to what we have with SQL databases, but for the FHIR API?

So I must ask, and hence the reason for this short article,

When did APIs become databases?

Some added context on what is FHIR: for my day job, I am the Interface Specialist for a Hospital. Interoperability in a Hospital setting is connecting independent systems with application programming interfaces (APIs). The most widely adopted interfacing format is HL7 version 2 the precursor to FHIR, aka HL7 version 4. For a very brief explanation besides the change in message formats, version 2 is 80's technology with TCP event emitters while v4 is trying to bring healthcare to the somewhat closer present with RESTful APIs and even a proposal for a GraphQL API. This is shaking up healthcare interoperability by providing means to query health data when you need it from remote systems instead of filtering, storing, and aggregating data received that may never be needed. And already before it is even widely implemented, there is this conversation comparing an FHIR API to that of an FHIR "database". 🤦‍♂️