Twitter recently announced they will no longer support free access to the Twitter API. Everyone seems up in arms about it and I can’t figure out what an API even is. What would doing something like this actually affect?
I’ve tried looking up what an API is, but I can’t really wrap my head around it.
Edit: I’ve had so many responses to read through and there’s been a ton of helpful explanations! Much appreciated everyone 🙂 thanks for keeping this doofus in the know
In: 419
In short: I would say an API is a packaged service with defined inputs it will take, and some useful thing it will do or some info it will fetch for you, etc. in a _defined and predictable way_. So you can ask it to do what you want, and it will do it for you. And you can automate/program this in code, since the predictable structure makes using the service repeatable and predictable enough to automate.
“An API”, in terms of a **web service** like Twitter, is really at least two things:
Most obviously it is: A series of “endpoints” (exact URLs) that you can poke a certain way (send web requests in a standardized format to) and certain useful stuff will happen, such as “you can ask our server HERE with THIS QUERY and we will give you THIS ANSWER back, dynamically as reflects the current state of… our data set/product/the world/whatever it is we have to offer.”
(Or for a more Twitter-ey example, “Send us a post HERE in THIS FORMAT and with THIS AUTHORIZATION METHOD proving you own account X and we will tweet it from account X.”)
It’s also: Some infrastructure that the provider runs, a server-side program, designed to handle those queries or “pokes” or whatever input the API can receive, and fetches/computes/looks up the answer, or does the thing you asked, and send whatever the result is back out to the person making the API request.
There is another kind of API, which would be an API for a **software library**, some code. You can download the entire library, and you can poke the library with certain _correctly formatted_ inputs from your main program, and the library will compute/fetch/return some useful output back to the rest of your program, or do some useful task, without you having to write that code from scratch yourself. Just call the library correctly, and it will do what it is programmed to do.
There can be a mix of both, where you can integrate a _software library_ into your program that will make the correctly formatted request to a _web service_ for you. (API inception, if you want to call it that. But it’s not that complicated really, just an example of both kinds of API being used at the same time.)
“API” stands for “Application Programming Interface”, and it lets you “interface” with a library or service by certain standardized methods (the standardized format of acceptable/valid input methods are part of the “API surface”) and as long as you use it right, you will get defined outputs or results back from it (the predictable format of these outputs, or predictable results, are also considered a feature of the “API”).
tl;dr “poke the API like this and it will do X. Poke it like that and it will do Y. Maybe you get some data out. Maybe it just does a task for you. Poke it wrong and you get nothing, try again.” Predictability makes it easier to automate using the service.
In some third sense: an API is implicitly a **promise** of providing a service to whoever pokes the API correctly. (Maybe requiring authorization, maybe just provided to the general public without needing to prove you are a subscriber, whatever.) If you stop running the server that responds to the requests, if you stop publishing a library, then practically speaking people will not be able to use it (or will want to move to something still supported by somebody, in terms of a software library).
Although if a company never promised in writing to provide the service, or in any legally binding way, they can probably stop providing the service at any time. But programmers expect stability, and if you can’t convince programmers your service will remain available (or if practically you do not keep your server running, if you stop maintaining your software library) they will be forced to move on. If they had been paid subscribers, and you had an enforceable contract with them, and you drop your end of the bargain, maybe that puts you in legal trouble. In Twitter’s case, I don’t think that’s what’s happening here, I think the API was provided for free with no explicit promises of availability? I dunno though, ask a lawyer. But when a provider announces they are making an API available, people go “great, I can use this.” They don’t expect it will vanish the next day with no prior warning.
When Twitter disabled (free) use of the API, they basically announced they were _not_ providing these publicly/freely available services — they will of course keep their own app working with their servers, using private/internal means, but aren’t letting arbitrary folks have access to make their apps work with the Twitter services anymore. (As I understand it from basically reading the headlines. Not an expert assessment in the slightest.)
Latest Answers