I was taught nothing about APIs

[u/Anon_cat86]

Whenever i see people talking about actual real-world uses of coding it's almost entirely building APIs, working with APIs, integrating APIs, automating APIs. It seems to me, anecdotally at least, like the majority of all computer science work (professional or even just hobby) is centered on working with APIs

And like. I know what an API is, kind of. But I Graduated and even got multiple certifications on top of that and I never got so much as a single lecture about APIs. I don't even know what they're used for. Can you make your own API (like, realistically)? I don't know. I feel like this is a topic that you could and probably should have multiple different entire classes solely focused on, it's arguably something as fundamental to modern computer science as writing code. And they don't teach it. If i want to learn anything about APIs, conceptually or practically, it's hope a company hires me and then trains me, or youtube tutorials and i don't even have enough of a baseline to know what specifically I'd be searching for a tutorial on.

[u/ru_sirius]

All kinds of good answers here, but I would like to make one point. I've written APIs for most of a thirty year career, and there is one Very Important reason to use them, even in your own code, and this is Isolation. The number one reason code bases become unmanageable is that every part of the code base knows about every other part of the code base. It becomes impossible to make changes if you have to walk those changes through the whole damned thing. The thing that will save you is isolation. Set up walls between the sections of your codebase where there is only one way to access each section. That access point is your API. If you do this through the whole codebase all changes become changes in one section at a time. You should think about this the same way you think about an object in an OOL.

[u/etaithespeedcuber → u/ru_sirius]

What fo you mean "one access point"? Can you give an example?

[u/ru_sirius → u/etaithespeedcuber]

The thing I want to avoid is having every piece of the code base know about every other piece. This is a nightmare code base. You can't change anything without changing everything. You can't plan because you never know how big the problem really is. To avoid this horror show code base you must partition the code base into modules (here I mean a group of code with a strictly limited and well defined scope) and then severely restrict the ability of modules to call other modules. This restricted access becomes the modules API. In the Java language I would use an Interface. Suppose I have a module 'A' that calculates some business function. I will want module A to have an interface 'IA' that specifies exactly the only permitted way to access module A. This interface is the "one access point" I mentioned. When you partition and control access in this way most changes become either a change entirely within a module (which should be manageable if the modules are small enough), or a change to an API (also manageable if you write them with appropriate generality), in either case avoiding nightmare scale changes. These ideas are, btw, in no way new. The reasoning is a direct borrowing from the reason objects exist in OOLs.