Imagine that we have to create a RESTful API to control a drone, also known as an Unmanned Aerial Vehicle (UAV). The drone is an IoT device that interacts with many sensors and actuators, including digital electronic speed controllers linked to engines, propellers, and servomotors.

The IoT device has limited resources, and therefore, we have to use a lightweight Web framework. Our API doesn't need to interact with a database. We don't need a heavyweight Web framework like Django, and we want to be able to process many requests without blocking the Web server. We need the Web server to provide us with good scalability while consuming limited resources. Thus, our choice is to use Tornado, the open source version of FriendFeed's Web server.

The IoT device is capable of running Python 3.5, Tornado, and other Python packages. Tornado is a Python Web framework and an asynchronous networking library that provides excellent scalability due to its non-blocking network I/O. In addition, Tornado will allow us to easily and quickly build a lightweight RESTful API.

We have chosen Tornado because it is more lightweight than Django and it makes it easy for us to create an API that takes advantage of the non-blocking network I/O. We don't need to use an ORM, and we want to start running the RESTful API on the IoT device as soon as possible to allow all the teams to interact with it.

We will interact with a library that allows us to run the slow I/O operations that interact with the sensors and actuators with an execution that happens outside the Global Interpreter Lock (GIL). Thus, we will be able to take advantage of the non-blocking feature in Tornado when a request needs to execute any of these slow I/O operations. In our first version of the API, we will work with a synchronous execution, and therefore, when an HTTP request to our API requires running a slow I/O operation, we will block the request processing queue until the slow I/O operation with either a sensor or an actuator provides a response. We will execute the I/O operation with a synchronous execution and Tornado won't be able to continue processing other incoming HTTP requests until a response is sent to the HTTP request.

Then, we will create a second version of our API that will take advantage of the non-blocking features included in Tornado, in combination with asynchronous operations. In the second version, when an HTTP request to our API requires running a slow I/O operation, we won't block the request processing queue until the slow I/O operation with either a sensor or an actuator provides a response. We will execute the I/O operation with an asynchronous execution, and Tornado will be able to continue processing other incoming HTTP requests.

Each of the following sensors and actuators will be a resource in our RESTful API:

The following table shows the HTTP verbs, the scope, and the semantics for the methods that our first version of the API must support. Each method is composed by an HTTP verb and a scope and all the methods have a well-defined meaning for all sensors and actuators. In our API, each sensor or actuator has its own unique URL: