Creation's API

NOTE: This was a draft I found of an un-published post prior to the redesign of HoD. There's good stuff in here, even if it is incomplete.

What?? So many posts in such a short time?! All I can say is: don't get used to it.

Creation()

I spend a fair amount of time thinking about how the various things I get up to interrelate and, in particular, how patterns from one domain can help shed some light on the other. Or, to put it another way: I love considering magic through the lens of software engineering (and vice-versa). Because, apart from a handful of hobbies, I mostly only get up to magic and software engineering (which aren't actually separate things, but let's just shelve that whole topic for the moment).

What if creation is essentially a massive production software system? No one, apart from the developers of the system (there's an entire rabbit-hole of spirits as reality engineers here), really knows what's happening on the inside of this black-box system, however, it's doing all kinds of shit (like creating all of reality). Most of the time, we interact with the output of this system: reality. But what does it mean to interact with the system itself?

Application Programming Interface

Let's talk about APIs. An API is a structured method for interacting with an underlying software system. Programmers create APIs that allow other programmers to use their system. I'll give a specific example for those that don't know what I'm talking about.

Square is a popular platform that provides payment and billing services for mostly small and medium sized businesses. You've probably used a website that relies on Square for payments (or, back before lockdown times, a physical payment device at a shop). Square runs a large production payment processing system which is essentially a black-box to anyone outside of Square. However, there is an API that makes it easy for programmers to use that underlying system to do all kinds of e-commerce things in their applications (like take credit card payments).

The Square API, like most modern-ish web APIs, follows a model called REST. The details of REST aren't super important here, however, there are a couple things you need to know for the remainder of this post to make any kind of sense. A REST API usually provides at least a way of getting things out of the underlying system, and a way of putting things into the system (otherwise it's not a very useful API). For example, the Square API provides a payments endpoint (endpoints are another interesting topic we are just going to skip over for now) that lets an application retrieve a list of payments that the application has received (i.e. the last month of payment transactions). The same payments endpoint lets an application create a new payment (i.e. when someone enters their credit card details in the application to buy something). In REST, the former is called a GET operation, and the latter a POST operation.

Divination as GET

Before we dig into creation's API, let's peel one more onion layer in the Square example. Square isn't a bank. They act as an intermediary betweens banks and businesses (because traditional banks are terrible at just about everything). The value Square provides is a really nice, well documented, easy-to-understand API that makes dealing with banks easier for businesses. Square also doesn't create money. Government treasuries create money. Square just helps it move around. The reason this is important in this context is that Square's core value is providing an easy-to-use interface to a bunch of far more complicated things that hurt most people's heads to think about.

Magic as POST

Authentication

Data Mesh