On Tue, Aug 25, 2020 at 8:11 AM Simon <simon.borde...@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.borde...@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-le...@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/O53NXLP4BBTRVOZLVRJCM772AYLGIDLH/ > 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
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/WXOYSSGCTKT7IVAQ6HP2CW7RM2N6C2BY/ Code of Conduct: http://python.org/psf/codeofconduct/
