This is a sponsored post by my friends over at SlashDB. The topic is chosen by me, but the work is funded by SlasDB, making sure I keep doing what I do here at API Evangelist. Thank you SlashDB for your support, and helping me educate my readers about what is going on in the API space.
When I take money from my partners, I am always looking for characteristics in their products and services that allow me to write honest stories about the solutions they provide. I can’t do this for all API companies that approach me, but the ones that are doing useful things, make it pretty easy for me. SlashDB helps me out on this front because they aren’t the shiny new startup doing APIs–they are the real world business helping other companies, organizations, institutions, and government agencies get a handle on their databases using APIs. One huge benefit of this process in my opinion is how it helps us get a handle on the schema we use, by letting a little light in on the process.
One of the main reasons our databases are such a mess is because they are hidden away behind a dark technical or organizational curtain, and there really isn’t much accountability regarding how we define, name, organize, and store our data. Of course there are exceptions to this, but a messy, bloated, unwieldy database is a hallmark of about 75% of the organizations I’ve worked with over my 30 year career. Central databases are often a mashup of years, even decades of creating databases, tables, and adding columns, often times occurring over generations of database teams. The result is often an incoherent mess regarding how things are named, with layers of cryptic field names, and irrelevant table names, which might seem normal until you go and try to expose these data resources to 3rd party and partner developers.
Many of the data APIs I come across in my research lack any API design investment. Meaning they didn’t take any consideration when it came to exposing backend databases as coherent paths, parameters, and other elements. Many API providers just spit out the database as a web API, and called it good enough. This can be very frustrating for many Restafarians, and API designers. I agree, and I would love to see more efforts from API providers when it comes to making their APIs more intuitive, and doing the hard work of understand what resources they have, and how to best present their resources to their consumers. However, I feel like just exposing your database as endpoints can be an important first step in the API journey, and one that isn’t always 100% dialed in on day one–that is ok. Just publishing APIs, even if they reflect exactly the table and fields structures behind, is still an important first step for many companies. Not everybody is API design ready, and having APIs can prove to be more important than good design practices.
As I was looking through SlashDB’s site looking for potential story ideas, I thought their approach to exposing database and tables as paths, and helping take the first step of evolving any database towards being an API was worth telling a story about. I know this is the stuff that drives API obsessed folks crazy, and feel I shouldn’t be encouraging people, but I think it is more important that folks are doing APIs, and have embarked on their API journey, over doing things perfectly. API providers like SlashDB aren’t the bleeding edge of API design technology, they are the industrial grade API deployment solutions folks need to go from database to API. So go ahead and publish APIs that look exactly like your database structure. I’m not going to shame you. I think letting the sunlight in a bit is way more healthier than waiting until you have the perfect design, or worse, never doing it at all.
Tools like SlashDB allow us to begin the long process of unwinding our legacy database schema, and start being more consistent in the vocabulary we use. Even though the first version might not be as coherent, and plain language as we’d like, publishing a web API from your backend database like SlashDB provides, at least gets things out on the workbench–allowing you to begin having a conversation with external partners about what the future of your schema should look like. You are never going to learn API design by keeping everything behind closed doors, and even though you are going to have to support your first version out of the box for a significant amount of time–at least you are pushing your schema forward, making it more usable by external partners, and (hopefully) open to discussions about why your database schema might not work 100% at the moment.
Database to API is something ALL companies, organizations, institutions, and government agencies should be doing in 2017. ALL your databases should have web APIs available, even if you are still using ODBC/JDBC and other connectivity options. If you have the time and resources to inject some healthy API design practices into the mix you should, however don’t let it hold back your API deployments if you can’t. You should be eliminating any obstacles between your backend databases and the applications that need access to this data. Even if you did have the time to think through your API design, there is good chance you will need to shift the design of your API down the road based upon the feedback of consumers. So, just get your APIs published today, and begin the hard work of getting a handle on your database schema–it is too important to put off until you have everything just right.
