Services

Architectures

An application can be seen as four components: data, data access logic, application logic, and presentation. These components can be distributed in many ways:

  • server-based: The server does pretty much all the work. Customers are very light.
  • client-based: The client does pretty much all the work. The server only saves the data.
  • peer-to-peer: machines act as client and server and share the work, which they do comprehensively.
  • client/server: The dominant architecture. The application and data access logic can be distributed between client and server. They can have multiple layers: 2, 3, N. Allows applications from different providers to be integrated using standard protocols. This is the dominant architecture.

Client/server architecture is usually data-centric: business logic is sandwiched between that data and the user interface, usually web. An example pattern is the MVC (model/view/controller).

If we look at the criterion of where the HTML of a web application is generated we can have:

  • The traditional: HTML is generated on the server.
  • The SPA (Single-Page Application): HTML is generated on the client, and data (JSON, usually) is exchanged with the server. On the server we implement APIs based on HTTP, which can be shared with different types of clients such as browsers or mobile applications.

When functionalities grow and are added to a solution, we run the risk of turning our application into what is called a monolithic application. Some architectural solutions propose solutions:

  • Microservice Architecture: It proposes completely independent services that provide self-contained functionality. All of them communicate with lightweight protocols (they can be heterogeneous) based on REST/HTTP thanks to a well-established contract (API). Based on the idea of the event loop.
  • Service Oriented Architecture (SOA): A similar solution to the above, but services communicate using a more complex middleware called enterprise service bus (ESB). Based on the coordination of multiple bus services.

APIs

The world is increasingly interconnected through APIs that provide services. These can be public, in order to add value to a company's business.

APIs are said to be managed when they have a well-defined life cycle:

CREATED ➡ PUBLISHED ➡ OBSOLETE ➡ WITHDRAWN

They are only published once they are well documented, with their quality of use rules, such as usage limitation. The standard and open way to describe APIs is through OpenAPI.

Example: Twitter API

HTTP

The HTTP protocol is implemented on top of TCP, usually on port 80. This allows us to implement an HTTP server using sockets.

To write the server, we need to be able to read an HTTP request and respond.

Request

request = Request-Line
             *(<message-header>)
             CRLF
             [<message-body>]

The Request-Line has the format:

Request-Line = Method URI HTTP-Version

The most common methods are GET/POST. The version, HTTP/1.1. The URI is just the absolute path part.

The most common headers are:

  • Host (required): Specifies the domain name of the server.
  • Accept: informs the server about the types of data that can be received.

The message-body is empty for the GET method, and contains the form fields for the POST method.

When it is POST, the Content-Type header is sent with the values:

  • application/x-www-form-urlencoded: values encoded in key-value tuples separated by &, with an = between key and value. Non-alphanumeric values must be encoded in percent code. In Java it can be done with URLEncoder.encode(query, "UTF-8").
  • multipart/form-data: transmission of binary data, eg a file.
  • text/plain: text format.

Response

response = Status-Line
            *(<message-header>)
            CRLF
            [<message-body>]

The Status-Line has the format:

HTTP-Version Status-Code Reason-Phrase

We have already seen the status codes. The Reason-Phrase is readable text that explains the code.

The most common headers are:

  • Content-Type: The MIME type (media) returned. May include the charset. Example: text/html; charset=UTF-8.
  • Content-Length: The number of bytes of content returned.
  • Date: The date of the returned content.
  • Server: The name of the server.

The message-body has the content of the fetched resource.

Cookies

Cookies are a mechanism that allows key/value pairs to be stored in the browser from an HTTP server. It can be used for different purposes, for example to identify a user session, or to select a display preference, such as language.

There are two headers associated with this mechanism:

  • Set-Cookie: header that is written from the server's response to assign a cookie.
  • Cookie: header that is read from the browser request with the values of the cookies stored there.

To delete a cookie, just send the empty cookie with a date in the old "expires" field:

  • Set-Cookie: nomgaleta=; expires=Thu, 01-Jan-1970 00:00:00 GMT;

Example GET/POST from an HTML form: The /form URI displays a form, which is filled out and processed by the /submit URI.

Cookie example: The /page1 URI stores a cookie, which is then available to other pages.

Redirection Example: The URI /page1 is redirected to /page2.