[MUSIC] Welcome to the third module of the Service-Oriented Architecture course. You're nearing the end of your journey with us. So far, we've talked about the ways in which web standards and web services are used. Now, you're going to learn about how REST Services are used in service- oriented architecture. You may have heard of REST architecture in your practices, maybe you haven't and that's fine. We're going to cover what at RESTful web service looks like and how it works. We'll also talk about a related topic, microservices. By the end of this module, you'll be ready to tackle the last of your capstone assignments. Let's begin. In this lesson, you'll learn about a style of web services architecture called REST, which stands for REpresentational state transfer. It's used in distributed applications by using HTTP to send messages to communicate between components. In the most basic terms, REST is a client-server architecture based on a request response design. The client send the request and the server responds. However, a specific feature of REST is that communication is resource based. This means that messages are sent as representations of resources. A resource can be any piece of information that is self-contained. Examples of resources are documents, images, object representations and so on. We will be looking more deeply into what a request and a response looks like in REST later on and why they are considered resource based. REST has five constraints that establish its defining characteristics. The first constraint is that REST is a client-server architecture. To refresh, a client-server architecture applies separation of concerns by having roles with specific responsibilities, the client and server, which interact with each other. The server provides services to the client, like creating or manipulating data, and the client provides users with a user interface to access these services. This separation allows REST applications to be highly scalable. It allows the development of the client and the server to occur independently of each other. Because the client is not concerned with data storage or manipulation, it can be improved to provide users with a simple and fast user interface. The server can also be more scalable, allowing larger sets of data to be manipulated, because it's freed from having to implement any client responsibilities. The second constraint states that REST is a layered system. It can consist of multiple architectural layers of software or hardware called by the client and server. These layers can be used to improve performance, translate messages, manage traffic and more. This helps to improve reusability of REST web services because layers can be added and removed based on the needed services of the client. The third constraint of REST architecture is that interactions must be stateless. This means that the server does not save information about the current client state or previous request made by the client. Other than when a request is made the server does not need to know that the client side exists. Additionally, each request is independent of each other and must contain all necessary information for the server to understand and respond to the request. If there's any information needed by the server to complete a request, the client must send it every time because the server will not rely on information sent from previous requests. Again, this constraint improves performance of web services because the server does not have to store any information about the current states of clients in the system. Without the overhead, the server can provide improved performance to the clients. However, this imposes significant restrictions on the way a client and a server communicate. Every time a client sends a request to a server, it must provide and store information about its current state in order to maintain this stateless constraint. For example, if authentication is needed by a server for a client to have access to data, the client side must send that authentication information in every request. The fourth constraint of REST is that clients can cache. This means that the clients can keep a local copy of a server response to use for later requests. Basically, every time a server responds to a client request, the server adds information to the response to label it as cacheable or non-cacheable. It does this to improve performance so that it can reduce the number of requests for the same resources. This can also relieve some of the negative impacts of applying the stateless constraint. The server decides for the client side what information should be temporarily saved and what can be deleted after use, so that the client does not keep any redundant or useless data. The fifth constraint of REST is that there is a uniform interface for communication between the client and server. What does this mean exactly? Firstly, this means that there are specific methods that are understood. REST used the common HTTP methods. Get, put, post and delete to communicate the different actions the client want to perform on the resource. Secondly, the resource must be identified in the request using a specific Uniform Resource Identifier, or URI. Lastly, the representations of the resources are uniform. Responses have specific headers, like if the data should be cached and the resources written in three specific ways, XML, JSON or Simple Text. Now, let's look at an example of a request and the response to better understand these constraints. Here you can see an example of a request being made by a client application to add coffee to an online shopping cart in the form of XML data. The request uses the HTTP method, PUT, to identify the method to call on the server. In this case, the client is asking the server to update the shopping cart by adding a new item to the shopping cart. The request identifies the resource and the URI, and the XML tells the server the specific shopping cart to add the new item to. The request is stateless because it includes the information needed to add the coffee item to cart identified as 1234 and the information about what the shopping cart previously included. A response from a web server may look like this. Here you can see a standard HTTP response in the form of a JSON object. The headers include a specific section called cache control, which determines if the information should be cached on the client's side. In this case, max-age=30 instructs the client to cache the information for 30 seconds. This response is information about an online shopping cart with five items, totaling to $70.51. To summarize, REST or REpresentational State Transfer has five constraints, as we mentioned in this lesson, client-server architecture, layered, stateless, cacheable and uniform interface. REST uses a client-server architecture with layers where interactions are stateless, responses are cacheable and a uniform interface is used for communications. These constraints makes REST a flexible, high-performance architectural style for building service-oriented systems based on web standards. It provides benefits, including high scalability, reusability and loose coupling that allow it to meet the needs of modern applications with millions of users.
