Adaption of Flask Blueprints to form ‘Endpoints’, with a focus on the path and method of a resource.
Class based views didn’t cut it for me, so this is what I arrived at.
Go from this:
` >>> blueprint = Blueprint('users', __name__, url_prefix='/users') >>> @blueprint.route('/<string:user_id>', method=['DELETE']) `
` >>> endpoint = Endpoint('users', '/users', __name__) >>> @endpoint.delete('/<string:user_id>') `
Makes sense for my purposes, and I can still include per-route decorators, which is where classed based views fell down for me. This makes an incredible amount of sense in a HTTP API implementation where you need fine-grained control. For example, in the event that you want to implement a ‘lockdown’ of your API, you can include a specific decorator for ‘changing’ endpoints.
` >>> @endpoint.post() >>> @lockdown(severity=2) `
` $ pip install flask-endpoint `
Or if you prefer easy-install:
` $ alias easy_install="pip install $1" $ easy_install flask-redis `
None (really!). Instead of running the following:
` >>> from flask import Blueprint `
` >>> from flask_endpoint import Endpoint `
` >>> endpoint = Endpoint('users', '/users', __name__) >>> @endpoint.post() >>> @endpoint.post('/url') >>> @endpoint.get() >>> @endpoint.get('/url') `
The package supports all of the methods available to flask (GET/POST/PUT/PATCH/DELETE/OPTIONS/HEAD).
All of the standard blueprint optional arguments will be passed through (sans url-prefix), which makes this fairly easy to adopt.
When it comes time to register them, do as you would a Blueprint:
` >>> app.register_blueprint(endpoint) `
TODO: Figure out how to actually get changelog content.
Changelog content for this version goes here.