> > > The standard library module http.server already has 2 request handlers, > with SimpleHTTPRequestHandler and CGIHTTPRequestHandler, the first serves > files from a directory, and the second executes CGI scripts. > > > > Two new handlers could be included in the standard library : > > > > - WebhookRequestHandler : Would spin up an HTTP server that one could > connect webhooks to. Webhooks are really useful when dealing with APIs. So > far, the third-party package, requests, is used when interacting with Web > APIs, but there is nothing in the standard library that implements the > webhook standard. > > > > - APIRequestHandler : This can be more controversial, especially with > third-party packages like Flask, starlette, and django that will be much > more powerful and secure than this, but this handler would be used to spin > up a server that would make it easy to serve a simple restful API. > > > > Not really in favour of "API" as a name. If you want a simple RESTful > API framework, I'd call it something with REST in the name. But I'm > not sure that that's needed, since you'd quickly outgrow a simple > class and need to go for Flask/Django/etc. > > Webhooks are very tempting. There's a lot to be said for properly > implementing this protocol in the standard library. It might be a bit > harder, though, since it basically wants asynchronous or threaded I/O. > Maybe this would be a good addition to asyncio? > > ChrisA
My idea behind the APIRequestHandler (by the way, RESTRequestHandler might actually be better) was to provide devs with a simple interface that doesn't require any setup in order to spin up RESTful APIs for personal projects. You're ultimately right, though, in that to scale up, a more robust framework is needed (as I previously mentionned, flask, Django and starlette are much more powerful than a simple class), but they come with their own drawbacks : they are not in the standard library, and they are very heavy. For a dev that just wants to spin up a very basic API, in order to expose their IoT devices to their network for instance, even flask is overkill. And because of the size of these modules, they are unsuitable for embedded development (on a raspberry pi compute module/zero, or with microPython). In my opinion, REST is the best protocol to make two pieces of software communicate with each other, because of its simplicity, yet, the standard library lacks in that regard in my opinion.
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/FQRBP5SMOFR4S7GUDTJKUEUK4F6MJUE5/ Code of Conduct: http://python.org/psf/codeofconduct/
