Re: [Paste] Using WebOb on the client side

Top Page
Author: Ian Bicking
Date:  
To: Martijn Faassen
CC: paste-users
Subject: Re: [Paste] Using WebOb on the client side
Martijn Faassen wrote:
> Hi there,
>
> On Thu, Jun 12, 2008 at 8:54 PM, Ian Bicking <ianb@???> wrote:
>> Martijn Faassen wrote:
> [snip]
>>> WSGIProxy - unreleased, but recent development activity is a bit younger
>>> than HTTPEncode.
>> I need to clean it up, but generally I would recommend WSGIProxy, and would
>> not recommend HTTPEncode. For a client
>> wsgiproxy.exactproxy.proxy_exact_request would be the best app, and it's the
>> thing least likely to be moved around in WSGIProxy.
>
> Right, I did find proxy_exact_request. Is there any chance WSGIProxy
> could be released to PyPI any time soon? What kind of cleanups would
> you like to do? It's just nicer to work with a release than it is to
> work with an SVN external.


Sure, it's long overdue for some kind of release. I'll put something
together today.

One caveat is that I haven't translated the response file object into an
iterator, so exactproxy reads the entire response into memory. (Maybe
an option to read it into a temporary file would be useful.) I thought
about fixing it, but it involved subclassing stuff from httplib and
doing lots of copy-and-paste to get at the socket object. At least,
that's how I remember it -- I wanted the iterator to return whatever
content was available, instead of just yielding blocks that might not
yet be available, and then blocking on the socket. Though yielding
blocks would be easy to do and might be an improvement. But this will
all be transparent as far as webob is concerned.

>>> Any (paste or non-paste) possibilities I missed? Is client-side WSGI the
>>> right direction to go? Anything to watch out for? Which one of these is
>>> recommended for my use case? Should I worry about the lack of releases?
>> I think WebOb specifically is a fairly nice client library, though it wasn't
>> entirely intentional. I've used WebTest (based on WebOb) to do functional
>> testing over HTTP before in the same manner.
>
> Yes, I'm quite interested in testing my client library and looked at
> WebTest. I'm not sure whether I can use WebTest though as I want to
> rest my own API which in turn makes HTTP calls. I figured WSGI would
> be a way to help there - hook it up locally for the tests, and for
> real use, use WSGIProxy.


Using WebTest for HTTP testing is more of an example of doing the same
kind of thing as you propose. Of course you'll want to test your client
library API directly.

For testing I think a simple setup would be like:

 >>> def test_app(environ, start_response):
... req = Request(environ)
... print 'Client request:'
... print req
... return response(environ, start_response)
 >>> clientapi.proxy_app = test_app
 >>> response = Response(body='[1, 2]', content_type='application/json')
 >>> clientapi.get_ids()
Client request:
GET /ids HTTP/1.0
Host: localhost
 >>> and so forth...

-- 
Ian Bicking : ianb@??? : http://blog.ianbicking.org

_______________________________________________
Paste-users mailing list
Paste-users@???
http://webwareforpython.org/cgi-bin/mailman/listinfo/paste-users