My Experience of APIs

I watched Nate Jones's TicTok last week. He talked about how APIs are becoming the interface to data. As I noodled on his words, I agreed with him, and it got me thinking about my history with APIs - more generally than his point.

I have been developing or calling APIs for a long time, and this got me thinking: weren't the MSDOS interrupts (related post) a form of API? We all know the right answer, so we will not say it out loud and move on.

But seriously. I remember creating an API for the DOS terminate and stay resident (TSR) module I wrote as the proxy for the server-based DBMS we wrote. This API used INT2F as the interface to the TSR.  We didn't expect CBASIC programmers to code to INT2F, so I had a callable C library that abstracted the internals. What we built was closer to something like ODBC, a generic API for retrieving data requiring you to write the query.

There was a period when our systems had a business layer and a data layer; the business layer represented business semantics, and the data layer represented the sproc/view/query/table structure. Weren't these all APIs? During the object-oriented period (which sounds like the Jurassic period), I didn't refer to them as APIs then; they were methods on an object.

We went from RPC to SOAP to REST, each an evolution to build distributed systems. All these are forms of APIs as well. Why? APIs are about creating a dependable contract that callers can depend on to create an outcome—not about the specific implementation technology. The "interesting" part of the API design process was how to design for reusability. And by interesting, I mean the part we spent a lot of time discussing. In the Enterprise IT space, we had enterprise architects who created taxonomies, libraries, and APIs that modeled the data and/or the business processes. Building models/services for the entire company didn't work, and a "single responsibility model" and "separation of concerns" were needed. Even now, we have engineers who have API design as a skill we depend on and use at some level of governance.

From these evolutions (and more) of APIs, I have learned they are hard. Why? Because API design is hard. Why? Because reuse is hard. This is why when we talk about APIs today, we don't think of them as static. Instead, we build them to be extensible as the needs evolve. Even designing for evolution, I have had more than my fair share of painful API deprecations.

I still love a good API design session.

Firehose Treatment - Open Wide

I needed to take a short bit of time off from blogging while I worked out the details of interviewing, negotiating and relocating (at least me) to Seattle from Connecticut.  I am now into my second week of work at the largest online retailer and the fire hose is blasting full force.

Being this big means that someone has already done a lot of thinking about how to make something massively scalable.  Back in "the day" I remember pouring over the Principles of Transaction Programming book by Phil Bernstein.  I knew this stuff inside and out and it still serves me.

 

Given the massive need for scalability I have had to dust of some new/old theories. ACID is out BASE is in.  Sure I have read about a bunch of these over the last few years, but it is different being at a place that is actually doing it.

Here is a list of things blowing my mind today...

1. Eventual Consistency - It will get there when it gets there.


2. Anti Entropy - Anything with the word entropy in it I find confusing.  So what is Anti-Entropy? :-0


3. AWS - I had to pay for this before, now everything we deploy is already running on this.  Note to self; shutdown my services and save a couple bucks.