Software architecture is an abstraction of the runtime elements of a software system during a phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture.

Software architecture is defined by a configuration of architectural elements-components, connectors, and data-constrained in their relationships in order to achieve a desired set of architectural properties:

• Component: This is is an abstract unit of software instructions and the internal state that provides a transformation of data via its interface
• Connector : This is an abstract mechanism that mediates communication, coordination, or cooperation among components
• Data: This is an element of information that is transferred from a component, or received by a component, via its connector

The REST architectural style...

REST is modeled around starting with nothing and then adding constraints. We will apply constraints to a software architecture, and your architecture will become RESTful.

Note that throughout Roy T. Fielding's work, he does not mention that REST has to be applied to the HTTP protocol. In our case, a client server will be the browser as the client and IIS as the server.

Note that the separation of the client and server allows abstraction. These two components can be built independently as well as deployed independently.

The...

As discussed earlier, REST is not a protocol, and it can be discussed without implementation. The key element of REST is the ability to add constraints to components, connectors, and data.

When you select a hyperlink where data needs to be transferred from the server to the client, the client needs to interpret the data and render it into a format to the user. How does the REST principle do this? The REST components transfer the data as well as the metadata to the client, with instructions to help the client compose the resource that it has requested:

HTTP stands for Hypertext Transfer Protocol. The very first version was 0.9; then came version 1.0.

The key difference between 1.0 and 1.1 is that the client makes a connection with the server and that connection is reused, whereas in HTTP 1.0, the connection is thrown away and for each request, a new connection is created. HTTP 1.1 is also derived by applying the REST constraints to 1.0.

A basic HTTP message is composed of a header and body.

When the client communicates with the server, it communicates via HTTP. The server responds to the client with messages and code.

There is a broad range of status codes, which indicate to the client what has occurred with the request that has been processed...

HTTP/2 is an optimization of HTTP 1.1. Many browsers already support HTTP/2; your Chrome browser does that already.

HTTP/2 is a combination of two specifications: Hypertext Transfer Protocol version 2 (RFC7540) and HPACK- Header Compression for HTTP2 (RFC7541).

When using HTTP/2 over Transport Layer Security (TLS), "h2" is used to indicate the protocol.

The "h2c" string is used when HTTP/2 is used over clear text TCP or when HTTP.1.1 upgrades.

An example of a GET request is as follows:

-RCF 7540 Section 3.2

This request is from a client that does not know whether HTTP/2 is supported. It makes a HTTP 1.1 request, but includes an upgrade field in the header, "h2c", and at least...

Messages are processed faster as they are in a binary format compared to text. Since they are in the native binary format over the wire, they don't need to translate from text to binary by the TCP protocol.

As the web has evolved, more data is sent from the server to the client and from the client to the server. HTTP 1.1 does not compress header fields. HTTP works over TCP and a request is sent over this connection, where the headers are large and contain redundant data. TCP works on Slow Start implemented by a network congestion-avoidance algorithm, which places packets over the network. If the headers are compressed, more packets can be sent over the wire. HTTP/2 fixed this problem...

The Richardson maturity model (RMM) was developed by Leonard Richardson. Commonly referred to as RMM, it is used to upgrade the standard of your API.

This is your traditional soap-based web service or the XML-RPC service. It uses HTTP, but it has one method and one URI. This method is usually POST and will return a heavy dataset. I am sure all of us have worked with this type of web service or might encounter it at some point. The entire database as a dataset is wrapped in this output.

Resources are exposed, but you still have...

We looked at the definition of REST and how REST is derived. When you look at the REST architecture, you should be able to depict it in three categories, as explained by Roy T. Fielding. One, the process view, describes how data flows from the client to the several components. Two, the connector view is specific to the exchanging of messages between components specific to resources and resource identification. Three, the data view of how the data that we referred to as representations is transmitted from the server to the client. It is very important to have a good understanding of the REST principles and that REST was applied to HTTP 1.0 in order to derive HTTP 1.1.

HTTP is a living example of the REST principles. Actions such as GET and POST are stateless, which is a principle of REST. The examples show how to construct an HTTP request and what the server sends back...