Goodbye APIs, hello ABIs

A more enlightened and self-evident approach to programming interfaces that was always under our noses.

The trusty old API

A basic concept in computer programming you have surely heard of before is the Application Programming Interface, or API. The idea is pretty simple: these are the interfaces we sometimes create, other times use, to leverage software created by others. APIs form the backbone of SaaS, and indeed all data companies writ large. If such companies were locomotives and data was their haul, APIs would surely be the rails upon which it all runs.

It is also no secret that APIs are a weapon to be leveraged against competition. In the last ten to fifteen years, incumbent technology companies like Twitter, Google, Facebook, Amazon and doubtless others have openly leveraged their control of APIs to crush independent developments such as third-party clients and software that either threatens their bottom line or offends their arbitrary sensibilities. One can dial this back further to the heyday of Microsoft antitrust with the likes of OS/2 and Internet Explorer.

This double-edged sword is a consequence of APIs being fundamentally abstract. They are a convention, and nothing more. If both parties don’t agree to follow it, the API is rendered useless; if the API author decides for any reason that they don’t wish for their users to do something with their code, they can restructure the API to prevent them from doing that. Google did this to kill comprehensive ad-blocking, so is anything really off the table? In this sense, APIs have an unlimited capacity for tyranny. So, what is there to be done?

Enter ABIs

Those who follow this weblog or my Twitter are probably familiar with my lasting obsession about C. I have wrote prolifically about how C is uniquely powerful, sorely misunderstood, and more. ANSI C is the basis for my own programming language called C*. But even as I am yet to author C* code in the wild, there are many concepts that are fundamental to the mechanicalist school of thought which can be applied regardless of what programming language you use. Central to mechanicalism is the concept of the Application Binary Interface, or ABI.

Conventionally, the definition of ABI most people use is quite narrow: ABIs define all of the ‘bylaws and trylaws’ used by operating systems to decide on how to handle calling conventions, ordering of structures, when and where to emit padding, and moreover how to translate the often ambiguous demands of abstract language standards into real, concrete binary limits. Here, however, we use a broader definition: ABIs define all of these things, but are understood as a general-purpose toolset that is centrally relevant to the programmer, rather than an opaque, ‘employees only’ sort of toolbox for implementing high-level languages like C.

This greater definition was provoked by my work in drafting C*. In leaning into the underrated strength of C called communicativity, the so-called ‘abstract machine’ used in C* to model programs was radically revisited, and what one might call the type system was reoriented completely around the bit. More generally, C* gives the programmer a complete toolset for defining their own ABI characteristics, both in the conventional sense of application plumbing, and in the broader sense of efficiently and independently interfacing with foreign systems.

Ironing it all out

Like APIs, ABIs are a medium to define conventions of interfacing between programmers. But unlike APIs, ABIs have a self-evident aspect about them: even without an explicit ruleset, ABIs can be reverse-engineered from instances of their usage. This puts adversarial programmers (hackers) on the same conceptual level as good faith programmers, centring the reality that all you can really trust is the layout of the bits you receive.

It makes concrete information fundamental to the abstract task of ingesting potentially untrustworthy data: when you receive bits on the wire, you have a straightforward logic with which to discern if those bits are sufficient to construct a meaningful message or not. Your trust model about the caller and their intentions is separated from this task of sanitation with crystal clarity.

Finally, it defeats the political weight carried by APIs by revealing them to be false idols; however practically difficult it may be to discern a public website’s true ABI, it is always possible, and with enough resources, practical. No public service can deny the true ABI underlying their services without ceasing to be public altogether.

There is always an ABI to what you are using. The question is, are you using it? Or is it hidden away behind an API of someone else’s creation? What do they have to gain by denying you that ABI? What do you have to lose by being stuck with that?