RESTpy 0.6.3

Routing

This package comes with a Werkzeug routing converter that recognizes UUIDs:

from restpy.routing import UuidConverter

Request/Response Hooks

The RestApplication constructor takes additional keyword arguments of request_hooks and response_hooks. These allow for functions to modify the request before it reaches the endpoint and the response before it is returned to the web server.

Request hooks must be a callable that accept one argument which will be the Werkzeug request object. Werkzeug uses read-only attributes in request objects so existing attributes cannot be modified. New attributes, however, may be added to the request. If the hook returns a Werkzeug request object then that request will overwrite the original request object.

Response hooks must be a callable that accept two arguments which will be the Werkzeug request and the Werkzeug response objects. These hooks may modify the attributes of the Werkzeug response object. If the hook returns a Werkzeug response object then that response will overwrite the original response object.

Included with this package is a pre-defined hook that may be used:

# A request hook that adds a UUID to the request object.
# UUID can be found at `request.uuid`.
# If a UUID is already present in the WSGI environ then it is used.
from restpy.hooks import unique_request

WSGI Middlewares

The RestApplication object is a plain WSGI application and is compatible with any WSGI middleware.

Included with this package are some pre-defined middlewares that may be used:

# Adds a UUID to the WSGI environ.
from restpy.wsgi import UniqueEnvironMiddleware

# Activates a Werkzeug response object and returns the final results
# to the WSGI server.
from restpy.wsgi import ResponderMiddleware

Pluggable Services

The RestApplication constructor allows for the first argument, normally a Werkzeug Map object, to be an iterable of service objects. A service object is a Python object with a urls attribute or a dictionary with a urls key.

The purpose of this feature is to allow for services to be developed independently and then merged together into a simple WSGI application. For example:

##################
# service_one.py #
##################

from werkzeug.routing import Rule
from werkzeug.wrappers import Response

class ServiceOneEndpoint(object):

    def GET(self, request):
        return Response("GET")

    def POST(self, request):
        return Response("POST")

    def PUT(self, request):
        return Response("PUT")

    def DELETE(self, request):
        return Response("DELETE")

# URL mappings are simple iterables containing Werkzeug `Rule` objects.
urls = [
    Rule("/service_one", endpoint=ServiceOneEndpoint)
]

##################
# service_two.py #
##################

from werkzeug.routing import Rule
from werkzeug.wrappers import Response

class ServiceTwoEndpoint(object):

    def GET(self, request):
        return Response("GET2")

    def POST(self, request):
        return Response("POST2")

    def PUT(self, request):
        return Response("PUT2")

    def DELETE(self, request):
        return Response("DELETE2")

urls = [
    Rule("/service_two", endpoint=ServiceTwoEndpoint)
]

##########
# app.py #
##########

from restpy.applications import RestApplication

import service_one
import service_two

application = RestApplication(services=[service_one, service_two])

From here the RestApplication object will build a Werkzeug Map that is a composite of the two services URL mappings.