A familiar HTTP Service Framework¶
import responder
api = responder.API()
@api.route("/{greeting}")
async def greet_world(req, resp, *, greeting):
resp.text = f"{greeting}, world!"
if __name__ == '__main__':
api.run()
Powered by Starlette. That async
declaration is optional.
This gets you a ASGI app, with a production static files server (WhiteNoise) pre-installed, jinja2 templating (without additional imports), and a production webserver based on uvloop, serving up requests with automatic gzip compression.
Features¶
A pleasant API, with a single import statement.
Class-based views without inheritance.
ASGI framework, the future of Python web services.
WebSocket support!
The ability to mount any ASGI / WSGI app at a subroute.
f-string syntax route declaration.
Mutable response object, passed into each view. No need to return anything.
Background tasks, spawned off in a
ThreadPoolExecutor
.GraphQL (with GraphiQL) support!
OpenAPI schema generation, with interactive documentation!
Single-page webapp support!
Testimonials¶
“Pleasantly very taken with python-responder. @kennethreitz at his absolute best.”
—Rudraksh M.K.
“ASGI is going to enable all sorts of new high-performance web services. It’s awesome to see Responder starting to take advantage of that.”
—Tom Christie, author of Django REST Framework
“I love that you are exploring new patterns. Go go go!”
— Danny Greenfield, author of Two Scoops of Django
User Guides¶
- Quick Start!
- Feature Tour
- Class-Based Views
- Background Tasks
- GraphQL
- OpenAPI Schema Support
- Interactive Documentation
- Mount a WSGI / ASGI Apps (e.g. Flask, Starlette,…)
- Single-Page Web Apps
- Reading / Writing Cookies
- Using Cookie-Based Sessions
- Using
before_request
- WebSocket Support
- Using Requests Test Client
- HSTS (Redirect to HTTPS)
- CORS
- Trusted Hosts
- Deploying Responder
- Building and Testing with Responder
- API Documentation
Installing Responder¶
$ pipenv install responder
✨🍰✨
Only Python 3.6+ is supported.
The Basic Idea¶
The primary concept here is to bring the niceties that are brought forth from both Flask and Falcon and unify them into a single framework, along with some new ideas I have. I also wanted to take some of the API primitives that are instilled in the Requests library and put them into a web framework. So, you’ll find a lot of parallels here with Requests.
Setting
resp.content
sends back bytes.Setting
resp.text
sends back unicode, while settingresp.html
sends back HTML.Setting
resp.media
sends back JSON/YAML (.text
/.html
/.content
override this).Case-insensitive
req.headers
dict (from Requests directly).resp.status_code
,req.method
,req.url
, and other familiar friends.
Ideas¶
Flask-style route expression, with new capabilities – all while using Python 3.6+’s new f-string syntax.
I love Falcon’s “every request and response is passed into each view and mutated” methodology, especially
response.media
, and have used it here. In addition to supporting JSON, I have decided to support YAML as well, as Kubernetes is slowly taking over the world, and it uses YAML for all the things. Content-negotiation and all that.A built in testing client that uses the actual Requests you know and love.
The ability to mount other WSGI apps easily.
Automatic gzipped-responses.
In addition to Falcon’s
on_get
,on_post
, etc methods, Responder features anon_request
method, which gets called on every type of request, much like Requests.A production static files server is built-in.
Uvicorn is built-in as a production web server. I would have chosen Gunicorn, but it doesn’t run on Windows. Plus, Uvicorn serves well to protect against slowloris attacks, making nginx unnecessary in production.
GraphQL support, via Graphene. The goal here is to have any GraphQL query exposable at any route, magically.