7 ms·

"So, instead of taking the WebOb approach of using WSGI as the common protocol between services, why not use HTTP itself? The rest of the world uses HTTP as the

"So, instead of taking the WebOb approach of using WSGI as the common protocol between services, why not use HTTP itself? The rest of the world uses HTTP as the most-common denominator after all." I agree with the assertion that HTTP is the most common denominator. # done from memory In [1]: from webob import Request In [2]: print Request.blank("http://google.com/index.html") GET /index.html HTTP/1.0 Host: google.com:80 Looks like HTTP to me. In [1]: from webob import Request In [2]: from paste.proxy import TransparentProxy In [3]: print Request.blank("http://google.com").call_application(TransparentProxy()) Yeah the syntax could be less verbose in WebOb, and there was discussion about a nicer client API at one time, but it's fairly trivial to roll your own. Though requests makes short work of common things, I think it actually abstracts some HTTP details more so than WebOb in a way that leaves the user less informed about what's going on in the HTTP, Basic Auth for example. Which makes it it's own protocol, just like WSGI. WSGI in my experience makes light work of implementing HTTP IMO, it's fairly easy to read the part of the HTTP spec you need to handle and then make that work in WSGI, I'm not so sure requests could make that any easier without intervention from the library authors. I think there's still a place for requests, but I don't see it as becoming the standard way to build HTTP Requests and handle HTTP Responses. I view it more along the lines of a library like mechanize, only nicer. It has it's place.

ianb 15y ago
Thanks for noting this (speaking as the WebOb author). I should say that I don't think WebOb is particularly contrary to the idea being put forward – instead, WebOb was written with this kind of concept in mind. Requests certainly adds a lot of stuff, some that is below WSGI (e.g., Keep-Alive – WSGI specifically avoids that level of transport), a bunch of stuff that is more stateful (the session stuff), and a bunch of stuff that just felt like it was moving around too much to put in WebOb (e.g., OAuth). That said, there's nothing keeping a client library from adding that. TransparentProxy for instance could instead be something that handles pipelining and statefulness, and perhaps also acts as a request factory. WSGI is rather helpful here because it does not try to touch those parts – it leaves things open for other tools to take control there. Also to make a better client library you could subclass Request and add functionality that is handy but hasn't been added to WebOb (WebTest does this for functional testing, as an example). Auth probably fits in there. Redirect handling could go in there somewhere too. But if you always redirect transparently then you've made permanent redirects useless. WebOb itself certainly isn't a client library, its scope is largely limited to representing HTTP requests and responses. But if you are looking for HTTP-related tools, it has a lot of them.

ianb 15y ago

Thanks for noting this (speaking as the WebOb author). I should say that I don't think WebOb is particularly contrary to the idea being put forward – instead, WebOb was written with this kind of concept in mind. Requests certainly adds a lot of stuff, some that is below WSGI (e.g., Keep-Alive – WSGI specifically avoids that level of transport), a bunch of stuff that is more stateful (the session stuff), and a bunch of stuff that just felt like it was moving around too much to put in WebOb (e.g., OAuth). That said, there's nothing keeping a client library from adding that. TransparentProxy for instance could instead be something that handles pipelining and statefulness, and perhaps also acts as a request factory. WSGI is rather helpful here because it does not try to touch those parts – it leaves things open for other tools to take control there. Also to make a better client library you could subclass Request and add functionality that is handy but hasn't been added to WebOb (WebTest does this for functional testing, as an example). Auth probably fits in there. Redirect handling could go in there somewhere too. But if you always redirect transparently then you've made permanent redirects useless. WebOb itself certainly isn't a client library, its scope is largely limited to representing HTTP requests and responses. But if you are looking for HTTP-related tools, it has a lot of them.