Book Image

Hands-On RESTful Python Web Services - Second Edition

By : Gaston C. Hillar
1 (1)
Book Image

Hands-On RESTful Python Web Services - Second Edition

1 (1)
By: Gaston C. Hillar

Overview of this book

Python is the language of choice for millions of developers worldwide that builds great web services in RESTful architecture. This second edition of Hands-On RESTful Python Web Services will cover the best tools you can use to build engaging web services. This book shows you how to develop RESTful APIs using the most popular Python frameworks and all the necessary stacks with Python, combined with related libraries and tools. You’ll learn to incorporate all new features of Python 3.7, Flask 1.0.2, Django 2.1, Tornado 5.1, and also a new framework, Pyramid. As you advance through the chapters, you will get to grips with each of these frameworks to build various web services, and be shown use cases and best practices covering when to use a particular framework. You’ll then successfully develop RESTful APIs with all frameworks and understand how each framework processes HTTP requests and routes URLs. You’ll also discover best practices for validation, serialization, and deserialization. In the concluding chapters, you will take advantage of specific features available in certain frameworks such as integrated ORMs, built-in authorization and authentication, and work with asynchronous code. At the end of each framework, you will write tests for RESTful APIs and improve code coverage. By the end of the book, you will have gained a deep understanding of the stacks needed to build RESTful web services.
Table of Contents (19 chapters)
Title Page
Dedication
About Packt
Contributors
Preface
Index

Designing a RESTful API to interact with a simple data source


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.

Note

We will definitely lose scalability for our RESTful API because we have the in-memory data source in the service, and therefore we cannot run the RESTful API in another IoT device. However, we will work with another example that is related to a more complex data source that will be able to scale in the RESTful way later. The first example is going to allow us to understand how Flask and Flask-RESTful work together with a very simple in-memory data source.

 

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.