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
Without analogies: it’s a way to programmatically interface with Twitter (= to interact with Twitter from code).
When you pull up Twitter you’re shown a nice visual interface with text and other types of media (sound, images, animations, videos) nicely laid out there. You may also be nagged to log in, to install the app, shown ads, etc. Your device is fingerprinted by them, your activity is logged, and so on.
As a programmer you don’t need or want this. You want to just query for things and receive responses. Or maybe you want to do bulk operations (scrape all tweets of x). Or subscribe for events (grab tweet if x sent one, etc).
This way bots (malicious and harmless ones) and applications could be built on top of Twitter. You could have Twitlonger check a post, grab all the tweet contents, and unroll for you. And so on.
By not providing an API this becomes harder to do, as developers will need to access the same interface a person does, and tear away all the irrelevant parts first. Even worse is when business interest doesn’t align with this, and the site is actively trying to throw off people’s code from being able to do so.
Now, that’s not what they’re doing – they’re making it paid for. But there’s little difference in practice sometimes. Whether this is a bad or a good thing, I cannot tell you. But providing free does cost Twitter bandwidth, therefore money, so it’s not like they wouldn’t have anything going for the decision.
say you go to a restaurant for a meal and are handed a menu.
you find something you want but have no knowledge or skill to make it on your own. also, you don’t work there. you don’t know how to send the order to the kitchen or make the food, so you tell the waiter what you want
the waiter knows what you want but isn’t a cook. the waiter doesn’t know how to make it, so they use the system that sends the order to the kitchen.
the system sends the order to the kitchen, the cook reads it, and makes what you want
in this analogy, you’re the user, the waiter is your application, the ordering system between the waiter and the kitchen is the API, and the cook is the program that actually controls things
as an example, take a pair of earbuds that have touch control. your earbuds may be made by sony, samsung, anker, seinnheiser, or any other manufacturer, none of whom need the actual programming to raise or lower the volume, pause music, or skip to the next track. all they need is to know the system provided by your phone’s music application to order those actions. that system is an API
in the analogy, the benefit of the API is that any person with serving experience can walk in off the street and work at a restaurant with entrees they’ve never made. all they need is a little training on the system for ordering them
When you use Twitter, you are “driving” your computer: You look at the screen, and you use your hands on the keyboard and the mouse to interact with it.
Computers without a “driver” don’t have eyes or hands, so they instead use an API to drive.
So an API is a way to “use” a website without having a “human” actually sitting there.
API stands for application program interface. API’s are bits of code which allow you to interact with things with your own code that you don’t have access to normally. They “expose” new data sources or outputs to your code.
Imagine you’re a programmer. You’ve just learned how to code in javascript, the language of the web. You can add numbers, you can do complex calculations, you can print to a console, because that’s what javascript is made to do.
However, what if you wanted to pull data from a site like Twitter, lets say for a research project? You can’t just write a program that does that because your program has no way of interfacing with the entity called Twitter.
So, javascript has an API which lets you send and receive “requests” over the internet. Twitter also has an API which will answer requests that are worded correctly with data from their site. So, these tools allow you to write a simple javascript program that pulls data from Twitter, a source that would be totally inaccessible otherwise.
The API is a way for other computers and apps to “talk” to Twitter servers (see newly posted tweets, post their own tweets, and do other automations) without having to use the official Twitter website or official app. It’s like a ‘back door’ for computer programmers.
This dude posted ELI5 and you guys are giving him essays
API is like using the McDonald’s app. It allows you to order food and look through menu but you can’t access any information outside of what McDonald’s allows you to on the app. Twitter example equivalent is removing the app
API is an Application Programming Interface. Ill skip past the authentication side, but really all websites pass data in a structured manner. In a simplistic API you can go to like mymusicsite/api/getSongById/SongId and the website will spit out a structured piece of information. You might get a json file which just says id=,name=,albumn=,songdatastream=, etc etc. The API is the full collection of those rules. You can link this to most programming languages to do stuff with.
Typically some super smart cookies will write up a library that organizes all of these rules. So a simplified program might just use the library and write something like login with this username and password and save the hall pass (token) the site gives me. Then use that hall pass with like “heres my tweet generate in code” to post a tweet.
So you can do all the crazy code stuff you want, like weather tracking, your instant news that follows popular websites, your automated song lyrics, and all the other fun stuff that makes Twitter fun, and then use that code snippet to post whatever information you’ve collected.
The API itself is just like a bank teller. They ask for your ID to make sure you are who you say, and then they’ll allow you do many things with your account based on your requests. The API/bank teller has access to the whole bank (more or less) but depending on who you are your ability to access and edit information is limited.
An API is the entry point of a system. Imagine the menu of a restaurant. That is the API to the kitchen. It tells you what the kitchen can do and how to access it. This has benefits for both parties. On one hand, you as the client do not need to know how the kitchen works in order to get your food. And the kitchen can more easily control their operation if they don’t have customers walking in their freezers to help themselves to what they want. As a matter of fact the kitchen can now completely forbid anyone that isn’t an employee from accessing their space, thereby making it even more secure and tightly controlled.
The API of an online service does the same. It’s the part of the system that clients like apps and websites can access. It says what data they’re allowed to see and how they can ask for it. Imagine if every app that wants to display a Twitter feed needed to know how to create one by directly accessing the miriad of Twitter databases. It’d never work and it’d be highly unsecure. So the API acts as a contract between the 2 parties to facilitate communication.
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.)
Lots of great analogies here! I thought maybe seeing something a little more concrete might be helpful:
API stand for “Application Programming Interface.” Broadly, an API is a set of rules that on program must follow to talk to another program.
If I wrote a program to do math for you, I might set up an API that says your code must look like this:
compute(operation_symbol, number_1, number_2)
example:
compute(“+”, 2, 3)
returns:
5
Now, other programmers know what they need to give me and in what order: a symbol, a number, and another number. And they know what to expect in response: a number.
On the internet, it is common to create APIs based on URLs. A programmer can request a specific URL, and the website will return some information. For example, maybe Twitter creates an API for querying a user’s last tweet.
They will document that if you request
www.twitter.com/api/user={user_name}/last_tweet
They will send back to you something that looks like
{
“user” : “@A_Cool_Username”
“time” : “2022-12-31 03:21:12 EST”
“text” : “Happy new years everyone. Giving up Twitter for my resolution. Peace!”
}
So now, you can write a program that can query a bunch of usernames and know exactly what you’ll get back every time (predictability is very important for programming). That means you could write your own app or make a bot that always tweets back when a specific person tweets or whatever.
There is a lot more complexity here, obviously (don’t @ me programmers lol), but that’s the gist of an API.
Closing down the API will mean that all sorts of apps, bots, news feeds, etc that were setup to interface with twitter in different ways won’t work anymore.
Latest Answers