Monoliths and Microservices

A monolithic application is an example of rapid development, where a development team expects to develop a product with a fast turnaround time. They write everything in a single package and deliver it to the client. It works fine for a few months or a year or two, and then a customer requests a design or architecture change.

To deal with complexity while supporting the idea of faster delivery, the best engineers in our software industry came up with new architectures. It defines specific properties for each business component and has dedicated services. A single business component or single responsibility service is called a microservice. In large software applications, multiple services work together to accomplish a single goal.

REST

A typical REST application architecture is shown in the figure

REST is an acronym for REpresentational State Transfer. A REST service that conforms to RESTful constraints is called a RESTful service.

The web has developed over a period of time, from Web 1.0 to 2.0, 3.0, and then to 4.03. Web 1.0 was for file sharing. Web 2.0 is human-centric and supports the Internet as a platform. Network 3.0 is an executable network that supports data sharing. Web 4.0 is the smart, intelligent web where machines are smart enough to load content for humans.

When developing web applications for the World Wide Web, the architecture should meet the growing demands and must include the following non-functional requirements.

efficiency
performance and scalability
reliability
reusability
portability
Modular
other

A REST service that conforms to the constraints of the RESTful4 architecture is called a RESTful service. These constraints are as follows.

client-server architecture
stateless
cache
Use of a layered system
unified interface
Support for encoding on demand

Client-server architecture supports separation of responsibilities. Clients are independent of servers. Clients or user interfaces can be developed independently without knowledge of the internal details of the server and its capabilities.

Statelessness helps improve the overall performance of the server. The server does not need to know or maintain the requested state/session. Its basic job is to provide responses without the need for sessions to trace the source. This is implemented by the HTTP protocol

Caching helps improve performance. If the same request comes from different users, it can be cached. HTTP has a feature that helps in caching responses. This helps to improve the efficiency of the server.

Using a layered system helps to solve more problems like authentication and security. Having a layered system facilitates quick root cause debugging.

The unified interface is the foundation of the RESTful architecture. It ensures that resources are identified based on URIs, such as /api/v1/products. Regarding the unified interface, just go through HATEOAS5 again.

Examples of code-on-demand support are Java applets or client-side JavaScripts. For testing RESTful API, the above understanding is enough. RESTful architecture uses HTTP as the protocol for communication between client and server. Since HTTP is a stateless protocol, the goal of RESTful architecture is scalability and performance, and since HTTP internally calls TCP for the connection between client and server, it is also reliable. Let's discuss HTTP in detail in the next section.

HTTP

The Hypertext Transfer Protocol (HTTP Hypertext Transfer Protocol) is used for communication between clients and servers in typical web applications.

The first base version is HTTP 0.9. Later, after several updates, it was released as HTTP 1.0. This version utilizes a separate connection for each request.

Version 1.1 of HTTP is by far the most popular and widely used version. This version fixes the lag issue. Header metadata and information are in text format. HTTP 2.0 performance-optimizes header metadata by using encryption; at the same time, messages are multiplexed between client and server for better performance. HTTP 3.0 is currently under development; it uses UDP as the transport layer.

HTTP 1.1 will be used throughout this article.

HTTP is an application layer 6 protocol that works over a TCP (http:// default port 80) or TLS (https:// port 443) encrypted TCP connection. TCP is the most reliable protocol; it guarantees 100% sending/receiving of packets without any loss. In case of loss, an error message will be sent to the recipient.

The HTTP protocol obtains resources from the server according to the request, such as obtaining HTML content or data in a specified format from the server. Before HTTP can fetch data from the server, the client must establish a connection with the server in order to fetch resources via HTTP. This is accomplished by three-way communication between the client and server over the TCP layer. The client sends a connection request to the server on the given port. The server acknowledges receipt of the request, and the client then acknowledges receipt of the request. In this way, a connection is established between the client and the server. Now through HTTP, the client can get the required information from the server. Once the connection is established, the client can send multiple requests over HTTP, and the server will send a response to each request.

The HTTP protocol is simple, extensible and stateless. We can read header information and message body. It can be easily adjusted between client and server if the usage or semantics of the header changes. The server does not remember the state of the request. It just sends the requested data and is open for new requests.

HTTP has a caching mechanism. Clients can send information in request headers to store responses in cache for a specified amount of time for later use to improve performance. HTTP also supports CORS; that is, if the request body or HTML has a different domain, this will be served to the client. HTTP also works on sessionId. The client sends a request and the server sends the sessionId in the response. Later, this sessionId can be used to authenticate the request. A typical server has a proxy between them to hide the server's IP from hackers. HTTP supports proxy servers that mimic real servers in real time.

Steps for an HTTP connection between a client and a web server: Step 1, establish a TCP connection between the client and the server. Step 2 Get resources from the server via HTTP. Through a TCP connection, the client can send multiple requests, and the server will respond with the required information through HTTP.

insert image description here

Header

Headers are part of every HTTP request/response and they define the flow of information between client and server. The most common fields in the header are Content Type, Content Length, Host, User-Agent, Accept, Accept Encoding, Accept Language, Connection, Cache Control, Age, Date, Expires, and Keep-Alive.

Headers are logically divided into three categories: request headers, response headers, and general headers. This can be seen in the browser's network tab after sending the request.

The request header mainly includes fields such as Authorization, Host, Accept, Accept-Language, Accept-Encoding, and Content-Type. The authorization field is used for authentication with the server. It specifies that the request is from an authorized client.

The response header has Expires, Content-Length, Content-Type, Cache-Control, Date and Keep-Alive fields. Content-Type provides the format of the response type, for example, whether the response is JSON or plain text. Keep-Alive is a timeout in seconds, which is the time allowed for the connection to remain open.

General header files have information about the request URL, request method, status code, remote address, and connection.

insert image description here
There is also a class of headers called presentation headers, which include content-type, content-length, and other fields related to the presentation of the response.

ask

Clients communicate with servers using HTTP requests. The request has request method, resource address (on the server) URI, request header and request body (body is optional), etc.

request method

The request method is the action the client wants to perform on the server resource. The most commonly used methods in developing API-based software applications are GET, POST, PUT, and DELETE. Others are TRACE, UPDATE, HEAD, CONNECT, OPTIONS, TRACE, and PATCH.

The GET method is used to get information from the server. The POST method is used to add a new object to the server resource. The PUT method is used to update an existing object on a server resource. The DELETE method is used to delete an object on a server resource. GET, PUT, and DELETE are equivalent methods; that is, if you perform the same call multiple times, the result will be the same. GET is also a safe method, it won't do any harm if you perform that call multiple times.

resource address

Resource addresses are defined by URIs, where URI stands for Uniform Resource Identifier. It is an identifier for a resource on the server, known as an endpoint of the service, such as /api/v1/products.

request header

The request header contains an Authentication field, used to authenticate the request on the server, and Content-Type, used to specify the type of content expected from the server resource.

Request Body

The request body has a format to follow, which is understood by the server resource or service endpoint. Typically, the response body is in JSON or XML format.

insert image description here

response

When a request reaches the server, it sends a response. The protocol used here is HTTP. It has status line, response headers and message body.

status line

The status line lists the protocol version, return status code, and status text. Status codes are often referred to as response codes.

response header

The response header contains information sent by the server to define the response information, such as Content-Length and Content-Type.

Response Body

The response body is the response message the server sends to the client for a request on a given resource.

insert image description here

response code

Information: 1XX-199
Success: 2XX-299
Redirection: 3XX-399
Error from client: 4XX-499
Error from server: 5XX-599

For example, the 102 status code means that the request from the client has been received and the server is working.

A 200 status code signifies that the request from the client was successful and accepted by the server.

A 302 status code means that the request was redirected to another resource.

A 400 status code indicates that the request from the client was wrong.

A 500 status code indicates that the server was unreachable or that there was a server error.

You only need to remember a few that are commonly used in API-based software applications. Knowing the response code is important for API testing because consumers of the API should know the response from the server and can take corrective action if something goes wrong.

Summarize

In this chapter, you learned about the types of web-based application architectures that are commonly used in the industry. You also learned about the communication aspects between client and server and these properties. You learned about HTTP, HTTP headers, HTTP requests, HTTP responses, and the various response codes found in typical web-based applications. In the next chapter, you'll learn about standard authentication.

In the end, many friends have the idea of learning. Here I shared the video tutorial of the test on station B. You can watch it by yourself: