A Client-Server pattern is network architecture pattern where one machine, the server, runs an application or provides a service to multiple client machines. A server-side application provides an application programming interface (API), a set of commands that client applications use to interact with it. This centralized approach allows one version of code to be developed, hosting the key features of the application or service independently of client-side hardware. Changes in the server-side application can affect its functionality regardless of what the client uses to interact with it, requiring little, if any, client-side changes. Conversely, client applications can be developed specifically for each potential hardware and operating system (OS) combination where the service is made available. This allows client-side applications to take hardware and OS specifics into accounts. For instance, Windows, Mac and Linux applications can make full use of a mouse and keyboard interface, whereas Android and iOS applications require a touchscreen interface.
The server-side application, as mentioned, is responsible for providing the key functionality of the service. In the case of Draw It or Lose It, a guessing game application, it chooses a clue image from the database, communicates it to players, then parses their guesses and communicates whether they are correct. This is accomplished through an API through which client applications (players) can request a new round and submit their guesses. Thus, the client and server parts of the game share as little information as absolutely necessary and are effectively isolated from one another. In particular, the client-side application never needs to be informed of the correct guess for a particular image, only whether the player’s guess was correct. In the Representational State Transfer (REST) architectural style, this is described as the separation of concerns.
Another key benefit of REST’s separation of concerns is the server application’s ability to work with any compatible client regardless of its hardware or OS. Concerns of user interface, and input and output are wholly relegated to the client. Thus, as long as a client application correctly interfaces with the server’s API, it can be customized as required by its hardware or OS. One reliable method of achieving this uniformity of interface is the use of the HTTP protocol and JSON text syntax, both widely-adopted standards in software development.
Client-side concerns stem from the same principles of the REST architecture. Since data storage concerns are isolated to the server, and the API for client-server communication is uniform, the parts of the code responsible for creating API calls and interpreting server responses can be developed once for all client types. The functions responsible for exchanging data between the client and the server, and the client’s user interface, conversely, must be handled by each type of client separately.
The continued development of a game service like Draw It or Lose It allows for multiple improvements both on client and server side. For instance, a client should be able to request the creation of a new user account from the server. This can be accomplished by creating a JSON string with the new user credentials, sending it via the server’s API, and receiving a response with the account creation status. If an account creation fails, for example, if the chosen name already exists, an appropriate error code or message should be shown to the user. Moreover, the server application can track each player’s performance across games and maintain a high score table to be delivered and displayed via another API call. Finally, expanding the client to work with other hardware and OS combinations would require creating new client applications making use of appropriate combinations’ input and output methods, as well as their user interface designs. The core API interactions, as mentioned above, can be ported from other versions with minimal, if any, changes.