Client - Server

Motivation

In order to:

• Keep (most of) the logic in a central place,
• Have better control over the logic,
• Allow several external parties (clients) to access the logic uniformly.

... the client - server style is used.

Typical RESPONSIBILITIES 

Server:

• Access the data store,
• Perform most business logic,
• Expose APIs for clients to consume.                               

Client:

• Communicate with the server,
• Handle user interactions,
• Display data retrieved from the server.                          

Web Protocols

Motivation

Due to the emergence of client - server applications, a new problem arose: handling the communication between the clients and the server.

Request - Reply: Http

HTTP is the main protocol used for internet-based applications.

It is a request-reply protocol: a client must make a request to a server, for which the server must give a response.

Limitation: the server cannot initiate contact with a client*.

*The newer SSE mechanism allows pub-sub type of communication.

HTTP Requests

Have a well-defined structure:

1. HTTP method: GET, POST, PUT, etc,
2. Request target: usually the path on the server,
3. HTTP version,
4. Request headers,
5. Request body (optional): informally called "payload".

HTTP Responses

Have a well-defined structure, always as a reply to a request:

1. HTTP version,
2. Status code: 200, 201, 400, etc.,
3. Status text: OK, Created, Bad Request, etc.,
4. Response headers,
5. Response body (optional): informally called "payload".

Payloads - JSON

The request and response payloads must be served in a well-known format. The most popular formats are: HTML, JSON, XML.

In A2 you already used HTML payloads, served by the React development web server.

For transmitting structured data, usually JSON is used because of easy handling in JavaScript (JSON.parse and JSON.stringify).

bidirectional - Websocket

For bidirectional communication between the server and the client, WebSockets may be used (among other technologies).

Usually, WebSockets are used to push events from the server (to trigger an update of the client U.I.).

REST

Introduction

REST is a style of building (web) services, usually on top of HTTP.

You define a set of resource types (e.g. students) and operations, then you map them to paths and HTTP methods. 

Resources should have a predefined data model, such that the request and response payloads use a predefined structure.

Example mapping

Example path and method mapping for students resource:

Usually for the query operation, most parameters are optional (so you can use just firstName or just lastName or both).

Best practices - HTTP Methods

• Use appropriate HTTP methods:
  • POST - for creating new resources,
  • PUT or PATCH - for updating resources,
  • GET - for reading resources,
  • DELETE - for removing resources,
  • HEAD - for checking resources for existance

Best practices - Status codes

• Use appropriate response status codes:
  • 200 OK - for successful calls,
  • 201 Created - for successful create calls,
  • 204 No Content - for successful calls with empty body,
  • 400 Bad Request - for malformed requests,
  • 404 Not Found - for missing resources,
  • 500 Internal Server Error - for other unexpected errors.

Best practices - Paths

• Use plural resource type names (e.g. students).
• Nest child resource paths if appropriate (e.g. /groups/1/students).
• Include the IDs directly in the path for operations targeting a single resource instead of query parameters (e.g. /students/1 instead of /students?id=1).

Best practices - Payloads

• Use JSON payloads. Optionally support other formats.
• In case of errors, also return JSON payloads.
• Have a consistent response structure:
  • Same structure for all types of errors.
  • Same structure for all resources of the same type.

Command

Overview

Design pattern which handles heterogeneous actions uniformly, executed by underlying "receiver" classes. Usually used when the application needs rewind, replay or undo support.

The command type indicates the action that should be carried out and the command fields hold any parameters for the action.

Pitfalls

• Not storing all the inputs needed to rewind the command (e.g. command execution influenced heavily by system state).
• Too granular commands, resulting in high memory usage and low performance (e.g. what if Word considered typing a single letter as a command).