[Web-SIG] [server-side] request/response objects

[Ian Bicking]

On Friday, October 24, 2003, at 03:20 PM, Greg Stein wrote:
> In the most recent incarnation of a webapp of mine (subwiki), I almost
> went with a request/response object paradigm and even started a bit of
> refactoring along those lines. However, I ended up throwing out that
> dual-object concept.
>
> When you stop and think about it: *every* request object will have a
> matching response object. Why have two objects if they come in pairs? 
> You
> will never see one without the other, and they are intrinsically tied 
> to
> each other. So why separate them?

The biggest justification for me is: because that's what everyone does. 
  SkunkWeb doesn't separate them, but I can't think of any others in 
Python.  The request/response distinction is ubiquitous throughout web 
programming.  I guess it's natural to people.  But it doesn't even 
matter why: it is the way it is.

Another justification is that the request is essentially static.  It is 
created and complete, then it is processed.  When the request is 
complete, the response has just barely begun existence.  The request 
object could very well be immutable at this point.  (Unfortunately that 
probably would make compatibility with previous code too difficult, but 
that's an aside)  You can very reasonably pass around the request with 
the expectation that the response will not be touched, or even vice 
versa (though that is less common -- which is a bit backwards if you 
follow a convention that the response belongs to the request).

The request and response aren't particularly interwoven either.  
Request cookies have nothing to do with response cookies (and any 
attempt to combine their semantics would be futile).  Request variables 
follow arcane paths through all kinds of representations when you trace 
them back to their source.

And then there's simply the naming issue: request and response are 
pretty clear names.  Everyone knows what they are.  Everyone can guess 
at their interface, and certainly can read their interface.  There's no 
compelling alternative name for the combined object -- "handler" 
implies almost nothing, "transaction" implies the incorrect thing, 
"connection" implies a low-level interface...

The difficulty of writing, say, request.response.write(something) vs. 
handler.write(something) doesn't seem like a big deal to me.

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org