The client - server model in HTTP

Throughout this chapter, we've been referring to communication over a network as simply happening between originating and target hosts, as if the two were functionally identical, depending on which was sending a packet. In the client-server model, however, the two hosts actually perform distinct and specific duties, and so they are not conceptually interchangeable. A client entity is one who requests, and is granted, use of the services or resources provided (or served) by the server entity. Servers do not make active requests of clients, except when necessary to complete a service request already made by the client (for example, requesting additional login information from the client, when the client has initiated the transaction by requesting protected data). Likewise, clients are not expected to serve any specific resources to the server, except the information necessary for the server to sufficiently process and respond to a request.

Today, it's not uncommon for two applications to use HTTP to interact with one another in such a way that, depending on the interaction, either application could be considered the client or the server. For example, a desktop finance application might be responsible for storing local user data, while also using a remote API to access live data feeds about current interest rates on different kinds of loans. Now suppose the authors of that desktop application want to periodically access information about users of their software. In the case of a user logging onto their application to look up market rates for mortgages, the desktop application will request information from the remote API; so the desktop application is the client, while the API is the server. However, when the remote software decides to query instances of its desktop application for user data, the roles are reversed. The remote software will request the data from known hosts of the desktop application; the remote software is the client, requesting information from computers running the desktop applications, which are the servers in this scenario.

Alternatively, an application or host might be the client of one remote host, while simultaneously operating as the server for a different remote host. Consider the case of an API that responds to requests by aggregating information from a number of other APIs. In the act of servicing requests by their downstream consumers, the application in question is very obviously a server. However, when the application requests information from other APIs upstream, it is acting as the client.

I bring these examples up to highlight the fact that the client-server relationship is mostly conceptual. The assignment of client or server roles to a given host is specific to a given interaction context. If that context changes, so too might the conceptual role of the hosts involved. It's important that we avoid confusion by only referring to clients and servers within the context of a specific interaction.