Note
This chapter is adapted from a portion of the WebOb documentation, originally written by Ian Bicking.
Pyramid uses the WebOb package as a basis for its request and response object implementations. The request object that is passed to a Pyramid view is an instance of the pyramid.request.Request class, which is a subclass of webob.Request. The response returned from a Pyramid view renderer is an instance of the pyramid.response.Response class, which is a subclass of the webob.Response class. Users can also return an instance of pyramid.response.Response directly from a view as necessary.
WebOb is a project separate from Pyramid with a separate set of authors and a fully separate set of documentation. Pyramid adds some functionality to the standard WebOb request, which is documented in the pyramid.request API documentation.
WebOb provides objects for HTTP requests and responses. Specifically it does this by wrapping the WSGI request environment and response status, header list, and app_iter (body) values.
WebOb request and response objects provide many conveniences for parsing WSGI requests and forming WSGI responses. WebOb is a nice way to represent “raw” WSGI requests and responses; however, we won’t cover that use case in this document, as users of Pyramid don’t typically need to use the WSGI-related features of WebOb directly. The reference documentation shows many examples of creating requests and using response objects in this manner, however.
The request object is a wrapper around the WSGI environ dictionary. This dictionary contains keys for each header, keys that describe the request (including the path and query string), a file-like object for the request body, and a variety of custom keys. You can always access the environ with req.environ.
Some of the most important/interesting attributes of a request object:
Also, for standard HTTP request headers there are usually attributes, for instance: req.accept_language, req.content_length, req.user_agent, as an example. These properties expose the parsed form of each header, for whatever parsing makes sense. For instance, req.if_modified_since returns a datetime object (or None if the header is was not provided).
Note
Full API documentation for the Pyramid request object is available in pyramid.request.
In addition to the standard WebOb attributes, Pyramid adds special attributes to every request: context, registry, root, subpath, traversed, view_name, virtual_root, virtual_root_path, session, matchdict, and matched_route. These attributes are documented further within the pyramid.request.Request API documentation.
In addition to these attributes, there are several ways to get the URL of the request. I’ll show various values for an example URL http://localhost/app/blog?id=10, where the application is mounted at http://localhost/app.
There are methods of request objects documented in pyramid.request.Request but you’ll find that you won’t use very many of them. Here are a couple that might be useful:
Many of the properties in the request object will return unicode values if the request encoding/charset is provided. The client can indicate the charset with something like Content-Type: application/x-www-form-urlencoded; charset=utf8, but browsers seldom set this. You can set the charset with req.charset = 'utf8', or during instantiation with Request(environ, charset='utf8'). If you subclass Request you can also set charset as a class-level attribute.
If it is set, then req.POST, req.GET, req.params, and req.cookies will contain unicode strings. Each has a corresponding req.str_* (e.g., req.str_POST) that is always a str, and never unicode.
Several attributes of a WebOb request are “multidict”; structures (such as request.GET, request.POST, and request.params). A multidict is a dictionary where a key can have multiple values. The quintessential example is a query string like ?pref=red&pref=blue; the pref variable has two values: red and blue.
In a multidict, when you do request.GET['pref'] you’ll get back only 'blue' (the last value of pref). Sometimes returning a string, and sometimes returning a list, is the cause of frequent exceptions. If you want all the values back, use request.GET.getall('pref'). If you want to be sure there is one and only one value, use request.GET.getone('pref'), which will raise an exception if there is zero or more than one value for pref.
When you use operations like request.GET.items() you’ll get back something like [('pref', 'red'), ('pref', 'blue')]. All the key/value pairs will show up. Similarly request.GET.keys() returns ['pref', 'pref']. Multidict is a view on a list of tuples; all the keys are ordered, and all the values are ordered.
API documentation for a multidict exists as pyramid.interfaces.IMultiDict.
Note
this feature is new as of Pyramid 1.1.
pyramid.request.Request.json_body is a property that returns a JSON -decoded representation of the request body. If the request does not have a body, or the body is not a properly JSON-encoded value, an exception will be raised when this attribute is accessed.
This attribute is useful when you invoke a Pyramid view callable via e.g. jQuery’s $.ajax function, which has the potential to send a request with a JSON-encoded body.
Using request.json_body is equivalent to:
from json import loads
loads(request.body, encoding=request.charset)
Here’s how to construct an AJAX request in Javascript using jQuery that allows you to use the request.json_body attribute when the request is sent to a Pyramid application:
jQuery.ajax({type:'POST',
url: 'http://localhost:6543/', // the pyramid server
data: JSON.stringify({'a':1}),
contentType: 'application/json; charset=utf-8'});
When such a request reaches a view in your application, the request.json_body attribute will be available in the view callable body.
@view_config(renderer='string')
def aview(request):
print request.json_body
return 'OK'
For the above view, printed to the console will be:
{u'a': 1}
For bonus points, here’s a bit of client-side code that will produce a request that has a body suitable for reading via request.json_body using Python’s urllib2 instead of a Javascript AJAX request:
import urllib2
import json
json_payload = json.dumps({'a':1})
headers = {'Content-Type':'application/json; charset=utf-8'}
req = urllib2.Request('http://localhost:6543/', json_payload, headers)
resp = urllib2.urlopen(req)
Sometimes it’s required that some cleanup be performed at the end of a request when a database connection is involved.
For example, let’s say you have a mypackage Pyramid application package that uses SQLAlchemy, and you’d like the current SQLAlchemy database session to be removed after each request. Put the following in the mypackage.__init__ module:
1 2 3 4 5 6 7 8 9 10 11 | from mypackage.models import DBSession
from pyramid.events import subscriber
from pyramid.events import NewRequest
def cleanup_callback(request):
DBSession.remove()
@subscriber(NewRequest)
def add_cleanup_callback(event):
event.request.add_finished_callback(cleanup_callback)
|
Registering the cleanup_callback finished callback at the start of a request (by causing the add_cleanup_callback to receive a pyramid.events.NewRequest event at the start of each request) will cause the DBSession to be removed whenever request processing has ended. Note that in the example above, for the pyramid.events.subscriber decorator to “work”, the pyramid.config.Configurator.scan() method must be called against your mypackage package during application initialization.
Note
This is only an example. In particular, it is not necessary to cause DBSession.remove to be called in an application generated from any Pyramid scaffold, because these all use the pyramid_tm package. The cleanup done by DBSession.remove is unnecessary when pyramid_tm middleware is configured into the application.
More detail about the request object API is available in:
The Pyramid response object can be imported as pyramid.response.Response. This class is a subclass of the webob.Response class. The subclass does not add or change any functionality, so the WebOb Response documentation will be completely relevant for this class as well.
A response object has three fundamental parts:
Everything else in the object typically derives from this underlying state. Here are some highlights:
Like the request, most HTTP response headers are available as properties. These are parsed, so you can do things like response.last_modified = os.path.getmtime(filename).
The details are available in the extracted Response documentation.
Of course most of the time you just want to make a response. Generally any attribute of the response can be passed in as a keyword argument to the class; e.g.:
1 2 | from pyramid.response import Response
response = Response(body='hello world!', content_type='text/plain')
|
The status defaults to '200 OK'. The content_type does not default to anything, though if you subclass pyramid.response.Response and set default_content_type you can override this behavior.
To facilitate error responses like 404 Not Found, the module pyramid.httpexceptions contains classes for each kind of error response. These include boring, but appropriate error bodies. The exceptions exposed by this module, when used under Pyramid, should be imported from the pyramid.httpexceptions module. This import location contains subclasses and replacements that mirror those in the webob.exc module.
Each class is named pyramid.httpexceptions.HTTP*, where * is the reason for the error. For instance, pyramid.httpexceptions.HTTPNotFound subclasses pyramid.Response, so you can manipulate the instances in the same way. A typical example is:
1 2 3 4 5 6 | from pyramid.httpexceptions import HTTPNotFound
from pyramid.httpexceptions import HTTPMovedPermanently
response = HTTPNotFound('There is no such resource')
# or:
response = HTTPMovedPermanently(location=new_url)
|
More details about the response object API are available in the pyramid.response documentation. More details about exception responses are in the pyramid.httpexceptions API documentation. The WebOb documentation is also useful.