That's actually a very broad question. In the most basic sense, a web API works when a client (like a Web browser) makes an HTTP request of some kind to a Web server. The server examines that request to figure out what the user wants, and then returns data in some format (like a page) that the client then examines to get what it wants. These are just about the only things that Web APIs have in common; I realize that this doesn't really answer your question, but I wanted to give a reason why the question is so broad.
There are all sorts of ways that a client could format its request, or that a server could format its response, and so in order for any of it to make sense, the client and server have to agree on some basic rules. Generally speaking, nowadays there are two very general styles that get used for this sort of thing.
Remote Procedure Call (RPC)
In an RPC style API, there's usually just one URL for the whole API. You call it by POSTing a document of some kind which contains information about what you want to do, and the server returns the document that has what you want. In general computing terms, the request document typically has a function name and some arguments.
Some standards for this style of API include XML-RPC and SOAP. These standards attempt to create a format that can be used to describe the function calls you're making, or even to describe the whole API.
REpresentational State Transfer (REST)
In a REST style API, you don't so much have a URL for the API as a name space: a server, or a folder inside of a server, where a lot of different objects reside, and every URL within this namespace becomes part of the API. Rather than telling the server that you want to use the API, the URL tells the server what you want to use the API on. You then use the HTTP method, and possibly the request body, to explain what you want to do to that object: GET (retrieve something that's already there), POST (create something new), PUT (replace something that's already there), or DELETE (get rid of something that's already there). There are a few other verbs you can use, but those are by far the most common.
So far, I haven't mentioned standard formats for REST. In theory, you could use just about any format. HTTP already provides for saying what you want to do and what you want to do it to, so the format of the request body could be just about anything: some representation of the object you want to create or replace. But in practice, REST authors tend to agree on a format anyway, because it would be difficult to make sense of every possible format.