New subject: Adding additionnal common request handlers to http.server

24 Aug 2020

      ...
Fair enough. I guess the real question is, how much advantage is
RESTRequestHandler over directly subclassing BaseHTTPRequestHandler?
Maybe it'd be worth it just to simplify that case.
ChrisA
Well, maybe an example would be more telling. Below is a basic usage of the
handler I wrote :

    @RESTRequestHandler.route('/get/', methods=['GET'])
    def get_obj(request, obj_id):
        objs = [
            {'bar': 'baz'},
            {'lorem': 'ipsum'},
        ]
        if obj_id > len(objs):
            raise HTTPStatusException(HTTPStatus.NOT_FOUND)
        return HTTPStatus.OK, objs[obj_id]
    @RESTRequestHandler.errorhandler('*')
    def handle_errors(r, exc):
        return exc.status_code, {'code': exc.status_code, 'message'
: exc.message}
    with HTTPServer(('localhost', 8080), RESTRequestHandler) as httpd:
        httpd.serve_forever()
This example demonstrates how such a handler would be used, using a syntax
that
flask users should be pretty familiar with. The handler integrates both a
route and
an errorhandler decorator, which can be used to add new routes to the API
that's being
built. It's not something that's in the standard library either. By the
way, RESTRequestHandler
subclasses SimpleHTTPRequestHandler.

Overall the advantage is pretty clear, it provides a much simpler API for
devs
who wish to spin up an API, which would be the ultimate goal of this PEP.
Not to mention,
the handler I wrote is 184 lines of code, having to reimplement for every
API is cumbersome.

Re: Adding additionnal common request handlers to http.server

Simon

Guido van Rossum

tags

participants (2)