Imagine that we have to configure the notification messages to be displayed in an OLED (short for Organic Light Emitting Diode) display wired to an IoT device. The IoT device is capable of running Python 3.7.1, Flask 1.0.2, and other Python packages. There is a team writing code that retrieves string messages that represent notifications from a dictionary and displays them in the OLED display wired to the IoT device. We have to start working on a mobile app and a website that has to interact with a RESTful API to perform CRUD operations with string messages that represent notifications.
We don't need an ORM (short for Object-Relational Mapping) because we won't persist the notifications on a database. We will just work with an in-memory dictionary as our data source. It is one of the requirements we have for this RESTful API. In this case, the RESTful Web Service will be running on the IoT device; that is, we will run the Flask development service on the IoT device.
We have chosen Flask because it is an extremely lightweight framework, we don't need to configure 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 consider that there will be a website that will be coded with Flask too, and therefore, we want to use the same web micro-framework to power the website and the RESTful Web Service. In addition, Flask is an appropriate choice to create a microservice that can run our RESTful API on the cloud.
There are many extensions available for Flask that make it easier to perform specific tasks with the Flask micro-framework. We will take advantage of Flask-RESTful, an extension that will allow us to encourage best practices while building our RESTful API. In this case, we will work with a Python dictionary as the data source. As previously explained, we will work with more complex data sources in forthcoming examples.
First, we must specify the requirements for our main resource—a notification. We need the following attributes or fields for a notification:
- An integer identifier.
- A string message.
- A TTL (short for Time to Live), that is, a duration in seconds that will indicate the time the notification message has to be displayed on the OLED display.
- A creation date and time. The timestamp will be added automatically when adding a new notification to the collection.
- A notification category description, such as Warning or Information.
- An integer counter that indicates the times when the notification message has been displayed on the OLED display.
- A Boolean value that indicates whether the notification message was displayed at least once on the OLED display.
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 of an HTTP verb and a scope, and all the methods have a well-defined meaning for all notifications and collections. In our API, each notification has its own unique URL:
|
HTTP verb |
Scope |
Semantics |
|
GET |
Collection of notifications |
Retrieve all the stored notifications in the collection. |
|
GET |
Notification |
Retrieve a single notification. |
|
POST |
Collection of notifications |
Create a new notification in the collection. |
|
PATCH |
Notification |
Update one or more fields for an existing notification. |
|
DELETE |
Notification |
Delete an existing notification. |
