[MUSIC] Welcome to the lesson on RESTful web services. In this video lecture, we will have a deep look at REST. But what is REST, actually? REST, or Representational State Transfer, is an architectural style. A set of guidelines to serve network applications. It specifies a set of constraints on developing web services, and if those constraints are met we call that service RESTful. The first constraint is the separation of the client and server functions and architectures. The client doesn't care about the task executed on the server. For example, database access or memory management. And the server doesn't care how the client operates. This way they both can be developed independently. Clients can send multiple requests, but these requests should be independent of each other. Responses should be clearly identified as cacheable or non-cacheable. This is more of a performance constraint. Multiple clients might request the same resource, and in this case, caching will help in reducing response time and reducing a server load. There should be a uniform way of identifying and accessing resources. Each resource must have a URI and representation. The representation can be in JSON or XML. The last constraint is that an application can have multiple layers. Layers between client and server, like cash servers and load balancers. If there is a load balancer between a client and a server, the client shouldn't see beyond the load balancer. And the server shouldn't be concerned with who the load balancer is talking to. This restriction reduces complexity and makes it easy to add and remove layers. As a design consideration rather than a constraint, there should be one to one mapping between CRUD operations. That is create, read, update, and delete operations, and operations provided by the server. In light of these constraints, let's look at how HTTP fits REST. HTTPs is stateless, it has a client-server model, it supports caches, and uses URLs to identify resources. The last design consideration is mapping of craft operations. This can be done by a HTTP methods as shown in the table. We see that it is simple to build a RESTful web service via HTTP. But why should we use rest when exposing the functionality of an embedded or cyber physical system to the web. First of all, a central idea of rest is a resource. A resource is a component of an application that can be uniquely identified. The same logic applies to embedded systems. We have resources in the form of sensor and actuators, which need to be individually identified and accessed. Identification is achieved via URI's, and they're representation via JSON. An access comes by a HTTP methods like GET and POST. In REST, we call for CRUD operations, create, read, update and delete. In most cases, these are the only operations that we need on our sensors. Create the stages, update them, or shut them off. REST and JSON, used together, create a lightweight representation of resources. Being lightweight makes it more power efficient. The statelessness of REST means that it is more memory efficient as a server doesn't store our main information about the state of the connection. So, not only does rest fulfill our design considerations, but it also fulfills real-world considerations related to limited power and memory. We looked into REST, and its applicability to embed in systems in general. Now we will talk about some best practices to follow when designing web-enabled embedded systems. First of all, identify the sensors or functionalities that are available to you, and then decide which ones you would like to enable as a resource. Each of these resources should have a simple and focused URI to identify and access them. And finally, what actions would you like to allow on each of these resources? To better understand, we will look at an example development board. On the screen, you see a Texas Instruments Smart RF06 Evaluation Board. It has an accelerometer, light sensor, LCD display, an SD card slot, and some push buttons and LEDs. In this case, it is easy to identify our resources. All of the mentioned components are resources that can be uniquely identified and accessed. The next step is to assign each one a unique and logical URI. Here you see an example mapping of URIs against each resource. The next step is to specify which operations you would allow on each resource. So when you enter in a browser the URL of whichever sensor you want to access, the response will depend on whether the specific HTTP method is allowed or not. If it's allowed you will get an okay status message with the value of the sensor. If the method is not allowed, you will get the method not allowed status message. On the screen you see an example mapping of methods to resources. As we will be only reading data from the accelerometer and licencer, the only method we can use is GET. An LED can have a GET method to tell us it status on or off and a PUT method to change that status. And LCD can be updated to output certain information, and for that we need PUT. If we are reading and writing to the SD card, we can have all of these methods, create a file, update a file, read it, and delete it. In this lesson, we looked at how the REST style of designing web services is beneficial for cyber physical systems, and then we described an example mapping of REST to an embedded development board. Next we will learn about another type of service called cloud computing. [MUSIC]
