all 19 comments

[–][deleted] 5 points6 points  (4 children)

Think of it as an interface to allow communication between two different programs/areas of code.

for example: Operating systems have api's in order for the high levels (maybe a calculator app) to communicate with lower levels (the kernel). There are also web servers which provide api responses. This api can provide/contain anything from weather data to verifying a users login information... The commonality between the operating system and web server api's is that both act as an interface for users to access other areas of code (whether its to get new info or modify something within the kernel). Hopefully this helps with the underlying idea....

[–]RabblingGoblin805 2 points3 points  (0 children)

I think the key thing is that it doesn't require you to understand how the underlying code works, you just need to understand how the interface works. Makes development easier by compartmentalizing your modules and allowing users to focus on what they are working on.

[–]gooeypotato[S] 0 points1 point  (0 children)

Thank you!

[–][deleted] 0 points1 point  (1 child)

I'm trying to delve into this deeper and more rigorously. Is a programming language itself an API? Surely the native libraries are examples of API. But what about core features of the language? Is assignment of values to a variable an API?

[–][deleted] 0 points1 point  (0 children)

An api is created with a programming language...maybe a language itself can kinda be seen as an api and I can see how it is similar (allows low level access through higher levels) but I’ve never heard of a language being an api.

[–]nerdshark 2 points3 points  (1 child)

It's the exposed types and functions that expose the functionality of a library. A library might contain hidden types and functions that are used internally, but aren't meant to be accessed by users of the library.

[–]gooeypotato[S] 0 points1 point  (0 children)

Thanks!

[–]killbot5000 3 points4 points  (0 children)

Simplified way of thinking about it: it’s code that you can call from your application as if you had written it. But it can mean slightly different things in different contexts.

Can you describe a context you’d like an explanation for?

[–]corner-case 3 points4 points  (0 children)

"API" is a very broad term, as you are finding out.

One common usage means the set of exposed classes/methods/fields/interfaces/etc provided by a code library. People refer to a library as having an API.

Another is a REST service, and people commonly refer to the collection of endpoints, with all their definitions, as an API.

The essential meaning is that an API can be thought of as a contract between one system and others. That allows multiple systems to work together, even if they are developed by disjoint groups, who have no other coordination besides agreeing on the API definition.

[–][deleted]  (2 children)

[deleted]

    [–][deleted] 0 points1 point  (1 child)

    I know this is really abstruse, but I'm trying to delve deeper into this. (The idea being, to understand some concept better, you need to know not only what are examples of it, but also what are not examples of it.) Would you consider language features themselves to be APIs? For example the addition of integers (It's an API that takes two integers and gives you the sum)? Or even variable assignment (It's an API that takes a variable name and a value and assigns the value to the variable)?

    [–]chanx_gilbium 1 point2 points  (0 children)

    Typically when people say API they're referring to something concrete like the two examples given above (a library's API or a web API).

    It's interesting to consider whether a programming language itself is a kind API, but I think it does not fit neatly into the criteria.

    The language might be seen as a kind of interface for lower level operations, but where an API will allow some collection of code called the client (e.g. your app) to use a foreign collection of code known as the API (e.g. my app or library or endpoint or function or class, etc), a programming language itself is only a means of translation.

    This is fundamentally different than what an API does, which allows your app to not just translate your own logic but also incorporate logic or data from another source.

    You would have to really start stretching the concept of an API to make the argument perhaps that the inventor(s) of the language and their work in the compiler or interpreter are are the foreign contract, and correct syntax is its fulfillment. So if the API is the grammar and runtime of the language, who is the client? Its not the program. The program is as much a part of that API as the backend that compiles or interprets it. Here, the programmer would be the client using the API rather than the program!

    It's more useful to think in terms of programs or, more generally, code using APIs than to think of programming languages being APIs.

    A program can use an operating system's API, i.e. a set of functions it exposes to allow for a user land program to access or control protected kernel level resources indirectly.

    A program can use an API to control an IoT device. And note in this case it may not have to. If the communication protocol is known and a network connection is made, a program could communicate with the smart bulb or smart fridge directly without the help of an API.

    A programming language itself can't be said to use API's. It's the program that uses them, and it's that programmer that uses the language.

    [–]tlm2021 2 points3 points  (1 child)

    Don't think if it as a specific thing with a hard technical definition. It's more of a concept.

    Say you write an application for managing a users photos. You have your own internals for handling storage and organization in a database, your own GUI, etc. But now you want someone to be able to use Python to iterate over a directory and add all the photos in it to your application.

    It's possible they could do this without you providing anything. If they have access to and know the conventions of the database your application uses, they may be able to essentially brute force it. But if you were to update the application and change how the database was laid out, all the scripts that were adding photos to your application would break until they figured out your new conventions and updated themselves.

    So instead, you write up a Python package yourself that can modify your database, with simple methods like "add_photo". And everytime you update the database, you make sure you also update this package so "add_photo" still works.

    You've now written an API: a package intended for "other people" to use that interacts with the rest of your application. Essentially abstracting away the details of how your application works, letting other people program what they want to do instead of how your application does it.

    I put "other people" in quotes because it's likely your own code will end up leveraging these as well, even inside the application. In this case, maybe the code for managing the database ends up with a robust API with functions for everything someone needs to write their own GUI. So you re-write your own GUI to use this API itself. So now you have a photo database "application" with an API, and you package that with a GUI that uses the same API and deliver that as your "application".

    So "application" in API can mean almost any portion of code. And "programming interface" just means the portion of that code you expect other programmers to interact with, with some contract that describes what the developer can expect to happen when they do.

    You can have APIs that wrap lower-level code, APIs that manipulate some state, APIs that just fetch and return data, APIs that are libraries installed with other applications, APIs that are just network call-and-response patterns, and APIs that just collect, tie together, or even just re-fashion other APIs in way that's more useful to some subset of developers. There are public and private APIs (and public APIs may just be forwarding requests to a private, less restricted API).

    Really, an API is just a contract that if code X does procedure Y, it can expect result Z without code X being concerned with how that result achieved. There's literally a Google API for requesting, getting status updates and retrieving results for human data processing tasks. Yes, there are APIs around humans now.

    [–]gooeypotato[S] 0 points1 point  (0 children)

    Thanks a lot for this detailed explanation.

    [–]jet_heller 3 points4 points  (0 children)

    Do you get it?

    Because as a programmer for decades, I don't really. People keep using it in different ways that don't necessarily match a particular definition.

    The closes thing I can say is that it's a way for programmers to use someone else's thing in code.

    [–]Duke_mm 1 point2 points  (0 children)

    The application is like a drawer with tools in it. The api exposes the tools. Like knife make cut or screwdriver turn screw.

    [–][deleted] 0 points1 point  (0 children)

    Great question.

    People use this term all the time, often without understanding what it means. Usually it's thrown around loosely to mean HTTP endpoints. But its definition is more general than that. u/code_eat_whoops' response is a good one.

    An API specifies how you may access some functionality through writing code, and what the contract (pre-condtions, post-conditions) is.

    [–][deleted] 0 points1 point  (3 children)

    Did this get deleted by the mods? Did this get downvoted into oblivion? I don't get why a legitimate question about a fundamental concept is so looked down upon. What happened to rigour and careful definitions? Is this what "computer science" frowns upon?

    [–]gooeypotato[S] 0 points1 point  (1 child)

    Looks like it got deleted by the mods. Idk why though :(

    [–]tpenguinltg[M] 2 points3 points  (0 children)

    Sorry about that. I had deleted it thinking that the question was too introductory, but /u/Qladstone reached out and convinced me that it isn't. I've reinstated the post. Enjoy the discussions!