I can't help the feeling that this is much more appropriate for PyPI than
for the stdlib. There are just too many different ways to do it. (For
example, what if the user isn't familiar with flask?)
On Mon, Aug 24, 2020 at 1:45 PM Simon <
simon.bordeyne@gmail.com> wrote:
> > 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/<obj_id:int>', 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.