concept client in category api
This is an excerpt from Manning's book Irresistible APIs: Designing web APIs that developers will love.
Figure 1.4. The basic interactions with an API are direct connections with the back-end server or servers, and a well-defined interaction with clients on the front end. This allows for countless frontend applications, whether mobile, website desktop, or system integrations, without changes to the back-end servers.
The term API has been used for most of the history of computing to refer to the interfaces between computer systems, or between different programs on an existing system. Frequently these systems were peers, where neither of the systems was specifically a server or a client. For instance, a mail server might have used a database to store information, but the systems were inherently designed together, tightly coupled to work together seamlessly. More recently the term has been expanded to include web APIs, systems where a client—which could be anything from a web browser to a mobile application—contacts a web server and operates on the data on that server. The main difference here is that the developers who are writing the clients aren’t the same as the developers writing the interface—the system is truly decoupled.
To understand the transactions between the client and the server in API interactions, you’ll need a basic grasp of how HTTP works. Chapter 4 covers this topic in more detail, but for now I’ll give you some high-level information about the protocol.
You’re probably most familiar with HTTP as the way web browsers get information from web servers. An HTTP transaction is composed of a request from the client to the server (like a browser asking for a web page), and a response from the server back to the client (the web page from the server, for a browser). First, I’ll describe the elements in an HTTP request. You’re familiar with the URL, the address that you type into the address box on a browser, but that address is only one portion of the information sent from your browser to the server in order to process a web request.
As with the associated curl request earlier, the debugging demonstrates that the client sends a request including the new information for the requested item. A PUT request replaces information for an existing item in the system. In the response, the server returns a response showing the new values for the resource. This returned object matches the object that was PUT to the system. Without HTTPScoop, this seems a little magical, but you should be seeing a pattern by this point; these common operations are direct mappings to system calls on the back end of the application.