A RESTful web server is a web application. This means we can leverage any of the popular Python web application frameworks. The complexity of creating RESTful services is low. The preceding examples illustrate how simple it is to map the CRUD rules to HTTP Methods.

Some of the Python web frameworks include one or more REST components. In some cases, the RESTful features are almost entirely built-in. In other cases, an add-on project can help define RESTful web services with minimal programming. For example, https://flask-restful.readthedocs.io/en/latest/ is a REST framework that can be used as a Flask extension.

Searching PyPI (https://pypi.python.org) for REST will turn up a large number of packages. There are numerous solutions that are already available. Most of these will offer some levels of simplification for common cases. 

A list of Python web frameworks can be found at https://wiki.python.org/moin/WebFrameworks. The point of these projects is to provide a reasonably complete environment to build web applications. Any of these can be used in place of Flask to create RESTful web services.

There are several compelling reasons for writing a RESTful service directly in Flask, and some are listed here:

• The REST service views are generally short and involve the minimal overheads required to deserialize JSON requests and serialize JSON responses. The remainder of the processing is unique to the problem domain.
• If there is unique processing that does not map to a REST package in an obvious way, it may be better to simply write the view functions. In particular, validation rules and state transition rules are often difficult to standardize and may be difficult to integrate with the built-in assumptions behind an existing REST package. 
• If there's an unusual or atypical access layer or persistence mechanism, many REST packages have default assumptions about database operations, and are often tailored toward a package such as SQLAlchemy; for example, https://flask-restless.readthedocs.io/en/stable/.

Security, in particular, can be challenging. There are several best practices including the following:

• Always use SSL. For final production use, purchase a certificate from a trusted Certification Authority (CA).
• Never encrypt or store passwords, always use salted hashing.
• Avoid building home-brewed authentication. Use project such as https://flask-dance.readthedocs.io/en/latest/ or https://authlib.org.

For the final production deployment, there are a number of alternatives. See http://flask.pocoo.org/docs/1.0/deploying/ for a long list of the ways that Flask applications can be deployed at scale.

Let's see how to use a message queue to transmit objects.