Let me give you a brief rest. Got you there. What I meant to say was let me give you a brief overview of Representational State Transfer. What exactly is REST? How do we make use of it in our React application, and how do we make use of this to communicate with the server? How does a server support REST API, and how do we access the REST API from our React application? Let's talk about that a little bit more in this lesson. I'm sure you've heard the term web services being mentioned in the IT world very often. What exactly are web services? Web Services are a way of designing systems to support interoperability among systems that are connected over a network like the internet as we see today. This is what we refer to as a service-oriented architecture. Now, what this means is that you provide a standardized way for two machines that are connected to the internet to be able to communicate with each other at the application layer level for web-based applications using open standards. Now, I have used a lot of jargon there. Let's try to break them down and understand a little bit about each of that in this lecture. Two common approaches that are used for supporting web services are SOAP. The Simple Object Access Protocol based web services which uses the web services description language for specifying how the two endpoints communicate with each other. Typically SOAP is based on using XML as the format for the messages being exchanged between the two endpoints. Representational State Transfer or REST also uses web standards, but the exchange of data between the two endpoints could be either XML or increasingly using JSON as the format. The REST way of interoperability is simpler compared to SOAP and hence, REST has found a lot wider deployment in the web services world. Typically, client-server communication is facilitated using REST where the server supports a REST API and the client can then invoke the REST API endpoints in order to obtain information or to upload information to the server. Again, I have mentioned the word invoke the REST API endpoints, so these are a few terms that I have used. Let's clarify some of these in the next few slides. Representational State Transfer is a style of software architecture that is specially designed for distributed hypermedia over the World Wide Web. Now this was first introduced by Roy Fielding in his PhD thesis. Now this is one of those PhD theses that actually produced something useful for the world. So this has found again a lot of traction in the web services world. This is a collection of network principles that outline how resources can be made available on servers and these resources can be accessed from clients by identifying the resources using rest API endpoints. Within Representational State Transfer, there are four basic design principles. First and foremost, REST is built upon HTTP protocol, so it uses all the HTTP methods that we have already seen in the previous lesson. Second, REST is designed to be stateless, meaning that the server doesn't store any information about the state after the communication is completed. So when a server receives the request, the server replies, and then after that it doesn't remember anything more about the conversation between the client and the server. Third, the REST way of providing resources is to expose a directory structure like URLs (Uniform Resource Locators - URLs). Fourth, the format for data exchange is typically JSON or XML or both can be supported using REST. One of the motivations for Roy suggesting REST as a way for supporting web services is that it captures all the things that are good about the World Wide Web and that made the World Wide Web successful. The use of Uniform Resource Indicators or Uniform Resource Locators (URLs) which allow you to address resources by specifying them as a URL. The second one, being a protocol that lives on top of HTTP protocol. HTTP has already found wide deployment in the internet. Third, the request response cycle that HTTP is well-known for. So you send a request, the server receives your request, processes the request, send the response to the request, and the client receives the response, acts upon that, and may generate further requests. So, this approach of the request response cycle is very well established with HTTP and the World Wide Web. Now, the HTTP protocol as we have seen earlier, we will use all the various verbs that HTTP provides. specifically, the GET, PUT, POST and DELETE for being able to specify operations to be done on resources that are stored on the server-side. So for example, if you do an HTTP GET request, you are asking for the server to return the resource. If you do a POST request, you're asking for the server to create a new resource. If you do a PUT request, you are asking for the server to update an existing resource. And if you issue a DELETE request, you are asking for the server to delete the resource that is identified by the particular URL. Also, it tries to preserve Idempotence. Some operations, when they are performed even repeatedly, will not cause any change of state. Some other operations, if you do them successively, they may cause a change of state. So you need to be careful about which operations can be repeated without any damaging consequences and which have to be very carefully done. In the REST world you often hear people talking about nouns, verbs, and representations. Now, we'll clarify each one of these in a little more detail in the next few slides. Nouns specifically refer to resources and these resources are usually identified by their URLs and these are unconstrained. Verbs are constraint and these specify the actions to be done on the resources and representations as we see. When the information needs to be conveyed from the server to the client or from the client to the server, how you encode the information. Typically, either using JSON or using XML. Resource is the key abstraction that REST works around. So, the information is abstracted in the form of a resource and the resource is identified by specifying it by using a URL. So, any information that can be encapsulated and be made available, can be identified as a resource. A piece of information like the current weather in Hong Kong could be a resource, an image could be a resource, a stock price information could be a resource and so on. So, whatever you define as a piece of information that a client may be interested in, can be identified as a resource. You can even deal with resources as collection of resources that the server may send up to the client. An example of how you name resources is illustrated here. So we use URIs to identify the source. A quick reading of these specification or the URIs here will easily enable you to understand what we are referring to by using these URIs. So, for example, something which ends with dishes/, you automatically assume that this is referring to a collection of dishes. But dishes/123 for example, might mean dish number 123 in this case and so on. So, it is very easy to save and you can specify a collection of resources and be able to identify them as a collection and then download them as a collection or you can identify an individual resource and say that you want that particular resource. Now, these resources can be organized into a hierarchy of the specification of this URI. So, as you traverse the path, you go from the more general to the more specific of the resource. This directory structure enables you to identify the resources that you use or provide from your server-side very easily. The second part of the REST API are the verbs. In particular, we are interested in the four verbs of HTTP the GET, PUT, POST and DELETE. In this case, these verbs will be mapped into actions that we want to be performed on the resource, on the server-side. A GET would mean you want to perform a read operation on the resource. So, which means that a client sending a GET request is indicating to the server that it wants to obtain a representation of that resource from the server-side to the client-side. A POST means that you want to create a new resource and then you will specify the details of the resource in the representation that is used for specifying the resource and then send that information over to the server-side, so that the server will create that resource on your behalf. A PUT would be modification of resources and a DELETE as you would expect is deletion of the resources. So, as you can see, the four verbs; GET, POST, PUT and DELETE, are mapped into the four CRUD operations that you can carry out on a database that stores these resources on the server-side, the READ, CREATE, UPDATE, and DELETE operations. Elaborating further, the HTTP GET is a way of specifying that you want the information or the representation of the resource to be returned to the client from the server-side. So, when you issue a GET request to a REST API endpoint, you are asking for either a collection of resources represented by URI or a specific resource which is identified by the ID of that particular resource, specified within the URL. So, as you see in this example, if you say, dishes/452, you are meaning to say that dish number 452 with the ID 452 should be returned to the client-side. Similarly, the POST operation as we saw is used to create the resource. So, when you create the resource, the content of describing the resource would be in the form of a JSON representation or an XML representation and that will be included in the body of the request message that is sent to the server-side. So, a POST operation expects a representation of the resource in either JSON or XML format in the body of the request message. When the server receives that request message, the server creates that resource on the server-side and then returns either a conformation or a error to indicate that the resource creation failed. Similarly, a PUT operation is used to update a resource. When you do a PUT operation on a resource on the server-side, you may send back the modification either by specifying only the partial modification that you want to effect on the particular resource in the body of the reply message or you may send the complete representation of the resource in the body of the message. Depending on the arrangement between the client and the server, the server expects the information to be passed on in the body of the request message. A DELETE operation as you would expect deletes the existing resource. Now, in this particular case, of course a DELETE operation would be idempotent because if you try to delete a resource and the resource exists, it will be deleted. If you are trying to delete a non-existing resource, it won't cause any further modification to the server-side, except that the server will reply with an error saying that the resource doesn't exist. But, nevertheless, DELETE is an example of an idempotent operation in this case. Similarly, the GET operation is also an idempotent operation because it is not making any modifications to the resource on the server-side. POST and PUT of course are going to modify the resource on the server-side, either create a new resource or modify an existing resource on the server-side. Of course, the representations, as I have been emphasizing, the two common formats for representing is either JSON or XML. The last part that we need to emphasize is that server-side should be completely stateless, which means that the server-side does not track the client state because if the server needs to track the clients state, it will not be scalable. So, for a scalable implementation of the server-side, you normally use a stateless server on the server-side. So, every request that the client sends to the server will be treated as an independent request and will not reflect upon previous requests that have already been handled by the server from that particular client. So, it's the responsibility of the client to track its own state, either in the form of using cookies or using a client-side database, whatever means that is suitable. Now, this approach where the client tracks its own state is a lot more scalable because each individual client will be responsible for tracking its own state. This is where the client-side MVC setup helps us in this regard. Finally, we are not yet done with REST. We will see more of REST in the exercises that follow in this particular lesson and then also we will see more details about REST usage in the rest of this course.
