Re: Adding additionnal common request handlers to http.server
I find that flask's approach to this is quite pythonic. It's also relatively easy to use and explain. With this approach, as demonstrated by the example I provided, any dev can spin up a server that serves an API in virtually no time, which is why, out of all the possible approaches (Having an App-like class, designing middlewares, a Resource object with get,post,put,delete methods etc), I personally find flask's is the most appropriate for quick prototyping. Furthermore, in the implementation I made of this request handler, I used nothing but built-in python types. Here are the implementations I thought of, both for the 'RESTRequestHandler' and the 'WebhookRequestHandler'. RESTRequestHandler <https://gist.github.com/Dogeek/dedcac029b8ad3e505acff7ecf3a25ed> WebhookRequestHandler <https://gist.github.com/Dogeek/82b01a10c45ffccd3c8206fa67b5f198> I also can't help but think that this would be a great addition for devs who cannot for one reason or another, use PyPI (for instance, restrictions imposed by the IT staff at their jobs) 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.
On Tue, Aug 25, 2020 at 8:11 AM Simon <simon.bordeyne@gmail.com> wrote:
I find that flask's approach to this is quite pythonic. It's also relatively easy to use and explain.
This is a good point, I think you distracted a bit earlier by saying it would be familiar to flask users. That's true, but not the point. Rather, we are going for, as you say, a pythonic, simple, easy to use and explain API. And this one is inspired by flask, which is a good thing, as flask is widely used and excepted, and has a reputation for being fairly easy to get started with.
I myself am not familiar with flask, and with a quick glance, your prototype made sense to me :-) I think this might be a good addition to the stdlib, but it's still a good idea to flesh out the API and documentation, and a package we can grab from PyPi would be a good way to test it out. And we'd want that as a backport anyway. Also, you can see if you get any uptake -- other than the "can't ue PyPi" use case, do folks find this useful for simple REST APIs that don't require templating, and ORMs, and web-based configuration, and sessions, and all that stuff that the more complete frameworks provide. So I encourage you to move forward with this and see where it goes. -CHB
With this approach, as demonstrated by the example I provided, any dev can spin up a server that serves an API in virtually no time, which is why, out of all the possible approaches (Having an App-like class, designing middlewares, a Resource object with get,post,put,delete methods etc), I personally find flask's is the most appropriate for quick prototyping.
Furthermore, in the implementation I made of this request handler, I used nothing but built-in python types.
Here are the implementations I thought of, both for the 'RESTRequestHandler' and the 'WebhookRequestHandler'.
RESTRequestHandler <https://gist.github.com/Dogeek/dedcac029b8ad3e505acff7ecf3a25ed> WebhookRequestHandler <https://gist.github.com/Dogeek/82b01a10c45ffccd3c8206fa67b5f198>
I also can't help but think that this would be a great addition for devs who cannot for one reason or another, use PyPI (for instance, restrictions imposed by the IT staff at their jobs)
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.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/O53NXL... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On Tue, Aug 25, 2020 at 7:15 PM Christopher Barker <pythonchb@gmail.com> wrote:
On Tue, Aug 25, 2020 at 8:11 AM Simon <simon.bordeyne@gmail.com> wrote:
I find that flask's approach to this is quite pythonic. It's also relatively easy to use and explain.
This is a good point, I think you distracted a bit earlier by saying it would be familiar to flask users. That's true, but not the point. Rather, we are going for, as you say, a pythonic, simple, easy to use and explain API. And this one is inspired by flask, which is a good thing, as flask is widely used and excepted, and has a reputation for being fairly easy to get started with.opriate for quick prototyping.
Personally I'm fine with just using third party libraries for this stuff, but in terms of whether this is Pythonic, the example has this: @RESTRequestHandler.route('/get/<obj_id:int>', methods=['GET']) def get_obj(request, obj_id): I think it should be written as: @RESTRequestHandler.route('/get/{obj_id}', methods=['GET']) def get_obj(request, obj_id: int): The former API is what Flask does and it makes sense because it's an old library. Nowadays type annotations are possible and make more sense. This is somewhat inspired by FastAPI which is also well liked: https://fastapi.tiangolo.com/#example. The curly brackets make a bit more sense to me as well but that's not really the point.
participants (3)
-
Alex Hall -
Christopher Barker -
Simon