Restish Resources — Restish v0.5 documentation

### Navigation

- index
- modules |
- next |
- previous |
- Restish v0.5 documentation »

Overview

# Restish Resources

## Our project resource

The root resource in your project looks like this

    import logging
    from restish import http, resource

    log = logging.getLogger(__name__)

    class Root(resource.Resource):

        @resource.GET()
        def html(self, request):
            return http.ok([('Content-Type', 'text/html')],
                "<p>Hello from myproject!</p>")

This is just an example to get you going. Lets take a look at what it does.

### Logging

    import logging
    log = logging.getLogger(__name__)

We think you should be using proper logging in your application so restish makes a logger available at the top of the sample resource. You don’t need to use this but we’ve found good logging to be incredibly useful.

### So what is a resource?

At it’s most basic, a restish Resource is anything callable that returns http content. However, restish provides a base class that allows resources to have children and to negotiate what content type to return.

Restish handles urls by first breaking them into segments. It then passes this list of segments to the root Resource.

The root resource uses its `resource_child` method to see if there are any segments it can ‘consume’. Once it has consumed segments (or not) it calls another resource and the process continues.

The process stops when a resource is called with no more segments to process.Content is then returned based on request method and content headers (i.e. `accept`).

We’ll look at the URL handling to begin with

## Resource URL Handling

The restish resource class implements a `resource_child` method which checks a set of `matchers` to see if any of them are successful. If they are not, then None is returned (which is the same as a 404 response).

A matchers is any callable that returns a resource and a list of remaining segments (or an empty list if there are no segments left).

Most applications will not use `resource_child` however as there is a ‘child’ decorator on the resource base class. This child decorator has various ways of matching parts of urls and dispatching to other resources that we will discuss now.

### Implicitly named child

this takes its segment match from the decorated method’s name and only consumes one segment.

For instance, this code will match a segment named `thanks` and ignore any remaining segments. So if this were a root resource, it would match `/thanks` and `/thanks/foo/bar`, amongst others.

    def thanks(self):
        return http.ok( [('Content-Type','text/html')], 'thanks' )

    @resource.child()
    def thanks(self, request, segments):
        return thanks()

If we wanted to pass the remaining segments onto another resource, we would use the following.

    @resource.child()
    def thanks(self, request, segments):
        return Thanks()

    class Thanks(restish.Resource):
        """ see later for content docs """

The Thanks resource would then have to process any remaining segments if there were any, and if not then the Thanks resource would provide content).

### Explicitly named child

Obviously this won’t work where you have urls with non-python method name characters (for example any file-like name with a period character). For this you can pass an explicit child name to the `resource.child` decorator.

    @resource.child('styles.css')
    def styles(self, request, segments):
        return http.ok( [('Content-Type','text/css')], 'body { color: red; }' )

### Chaining Resources

Most applications will handled nested resources.

We’re showing a contrived example where the url `/blog/entries/28` get’s passed down from resource to resource.

    class Root(resource.Resource):

        @resource.child()
        def blog(self, request, segments):
            return Blog()

    class Blog(resource.Resource):

        @resource.child()
        def entries(self, request, segments)A
            # The segments contain everything below /blog/entries
            # Pass the first segment through to Entry (should be entry id)
            # The empty tuple says pass no more segments to Entry
            return Entry(segments[0]), ()

    class Entries(resource.Resource):

        def __init__(self, id):
            self.id = id

        @resource.GET()
        @templating.page('entry.html')
        def entry(self, request):
            blogcontent = db.get(self.id)
            return {'content': blogcontent}

### Handling it yourself

If you want to handle the url matching yourself then you can use the resource.any matcher. This literally matches any pattern and consumes nothing. This means you have to work out what path segments you want to pass on to the next child.

    class Root(resources.Resource):

        @resource.child(resource.any):
        def child(self, request, segments):
            # At his point segments contains all the segments
            if segments[0] == 'mymatchingsegment':
                # now I've matched a segment, I need to return the rest as follows
                return MyMatchingResource(), segments[1:]

### Template Resource Matchers

OK so that wasn’t the most realistic example, for sites like blogger you would want to pick up the year and month and then the blog entry name. We can do this using the template style url matcher. We’ll try that now..

    class Root(resource.Resource):

        @resource.child('{year}/{month}')
        def blog_month_entries(self, request, segments, **kw):
            return BlogList(**kw), segments

        @resource.child('{year}/{month}/{entryid}')
        def blog(self, request, segments, **kw):
            return BlogPost(**kw), segments

    class BlogList(resource.Resource):

        def __init__(self, year=None, month=None):
            self.year = year
            self.month = month

        @resource.GET()
        @templating.page('EntryList.html')
        def entrylist(self, request):
            entries = db.get(year=self.year, month=self.month)
            return {'entries': entries}

    class BlogPost(resource.Resource):

        def __init__(self, year=None, month=None, entryid=None):
            self.entryid=entryid

        @resource.GET()
        @templating.page('Entry.html')
        def entry(self, request):
            blogcontent = db.get(self.entryid)
            return {'content': blogcontent}

This works because when we have more than one matcher, the Resource works out which one to use based on a calculated ‘specificity’; The more specific match gets used.

### Which child to use?

Here are some examples from the unit tests.

    @resource.child('a/b/c')
    @resource.child('a/b/{c}')
    @resource.child('a/{b}/c/{d}')
    @resource.child('a/b/{c}/{d}')
    @resource.child('a/{b}/{c}')
    @resource.child('a')
    @resource.child('{a}/b/c')
    @resource.child(resource.any)

We’ll look at a few different matches to work out why they match

#### /a/b/c

    @resource.child('a/b/c')
    @resource.child('a/b/{c}')
    @resource.child('a/{b}/{c}')
    @resource.child('a')
    @resource.child('{a}/b/c')
    @resource.child(resource.any)

All of these resources match this url but we have an exact match so the first wins.

#### /a/b/foo

Only these match

    @resource.child('a/b/{c}')
    @resource.child('a/{b}/{c}')
    @resource.child('a')
    @resource.child(resource.any)

The specifity is calculated to the top level matches are considered more specific. In this case the first wins

#### /a/b/c/foo

    @resource.child('a/{b}/c/{d}')
    @resource.child('a/b/{c}/{d}')
    @resource.child(resource.any)

This has the same number of exact matches but the second has matches higher in the url hierarchy so number two wins.

#### /a/foo/c/bar

    @resource.child('a/{b}/c/{d}')
    @resource.child('a/{b}/{c}')
    @resource.child('a')
    @resource.child(resource.any)

In this case, the first match has more exact matches and so wins.

#### /a/b/foo/bar

    @resource.child('a/b/{c}')
    @resource.child('a/b/{c}/{d}')
    @resource.child('a/{b}/{c}')
    @resource.child('a')
    @resource.child(resource.any)

This one is a little more difficult but because we have an exact match on the number of segments, number 2 wins

### Custom Matchers

You can pass your own matchers to the child method if you like. For instance, let’s process the following search url `/search/python?u=foo`

    def mymatcher(request, segments):
        if len(segments) >2 and segments[0] == 'search':
            category = segments[1]
            search_string = request.GET.get('u',None)
        return {'category': category, 'search_string': search_string}, ()

    class Root(resource.Resource):

        @resource.child(mymatcher)
        def search(self, request, segments, **kw):
            return SearchResults(**kw)

    class SearchResults(resource.Resource):

        def __init__(self, **kw):
            self.category=kw.get('category')
            self.search_string=kw.get('search_string')

        @resource.GET()
        def html(self, request):
            results = indexer.get(category=self.category, search_term=self.search_term)
            ...

### ‘Parse it all yourself’ matcher

Sometimes you might want to process all of the segments yourself

    class Root(resource.Resource):

        @resource.child(resource.any)
        def process(self, request, segments):
            if 'blah' in segments[0]:
                return Matched(segments[0]), segments[1:]

The resource.any matcher does nothing and hence will pass all the segments into the child resource and then it is up to you to do what you will.

You should return do whatever matching you want and then return a resource and any remaining segments that you haven’t used (i.e. that you wish your matched resource to have available)

## Request Handlers

At some point, all of the segments will have been consumed. The final resource is then called in order to get the contents. If this resource is a restish resource, a series of tests are done to find out which method to use. Firstly the request type is used to find out which handler to.

The resource class also carries most of our resource decorators and can be used for url handling or http procesing. Here were are have decorated a method of our Root resource with a resource.GET(). This tells the resource to use this method for any GET responses.

Note

Matt: add a bit about resource http handlers

Responses should always be either http response codes or a callable that will generate a response.

Note

Matt: add a bit about http responses

In this case we have returned a http response with a content type of text/html. Let’s take a look at it.

    http.ok( [ ('Content-Type', 'text/html') ], "<p>Hello from myproject!</p>")

The response is a list of tuples, each of which is a http header key and value. This is followed by the data for the http response.

If we can work out the content type of the returned content from it’s accept header then we don’t have to explicitly provide it. e.g.

    http.ok( [], "<p>Hello from myproject!</p>")

### Other HTTP Handlers

Restish implements resource decorators to handle GET, POST, PUT and DELETE.

### Other restish http response codes

We can also return a whole range of http responses.

Note

Returning `None` from a resource is equivalent to a 404

`restish.http.` `ok`(headers, body)

  The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

  GET an entity corresponding to the requested resource is sent in the response;

  HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;

  POST an entity describing or containing the result of the action;

  TRACE an entity containing the request message as received by the end server.

`restish.http.` `created`(location, body, headers=None)

  The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.

  A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, see section 14.19.

`restish.http.` `moved_permanently`(location)

  301 Moved Permanently

  The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

  The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

  If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

  Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.

`restish.http.` `found`(location)

  302 Found

  The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

  The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

  If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

`restish.http.` `see_other`(location)

  303 See Other

  The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

  The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

  Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.

`restish.http.` `not_modified`()

  301 Not Modified

  If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.

  The response MUST include the following header fields:

  > - Date, unless its omission is required by section 14.18.1

  If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.

  > - ETag and/or Content-Location, if the header would have been sent in

  a 200 response to the same request

  > - Expires, Cache-Control, and/or Vary, if the field-value might

  differ from that sent in any previous response for the same variant

  If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.

  If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.

  If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.

`restish.http.` `bad_request`(headers=None, body=None)

  400 Bad Request

  The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

`restish.http.` `unauthorized`(headers, body)

  401 Unauthorized

  The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in “HTTP Authentication: Basic and Digest Access Authentication” [43].

`restish.http.` `forbidden`(headers=None, body=None)

  403 Forbidden

  The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

`restish.http.` `not_found`(headers=None, body=None)

  404 Not Found

  The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

`restish.http.` `method_not_allowed`(allow)

  405 Not Allowed

  The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.

`restish.http.` `not_acceptable`(headers, body)

  406 Not Acceptable

  The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.

  Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

  > Note: HTTP/1.1 servers are allowed to return responses which are not

  acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable.

  If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.

`restish.http.` `conflict`(headers, body)

  409 Conflict

  The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough

  information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.

  Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can’t complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.

## Content Negotiation

Resources can perform content negotiation in a few different ways. The example above where `GET()` had not arguments accepts any (or no) content type. If we wanted to explictly return different types of document depending on the accept headers we can include this as a GET argument.

    @resource.GET(accept='application/json')
    def json(self, request):
        return http.ok([('Content-Type', 'application/json')], "{}")

In this case, if the accept header was application/json, our empty json string would be returned.

If we had our argument-less GET resource also, then this would act as a ‘catch-all’ where everything apart from ‘application/json’ would return html. e.g.

    @resource.GET()
    def catchall(self, request):
        return http.ok([('Content-Type', 'text/html')], "<strong>I'm HTML</strong>")

    @resource.GET(accept='application/json')
    def json(self, request):
        return http.ok([('Content-Type', 'application/json')], "{}")

We can also use file suffixes and let the mimetypes module work out what content type to use. e.g. `html`, `xml`, `pdf`. We’ve also added `json` as we think you might (should) be using this one a lot! If you want to respond to multiple encodings, give it a list (e.g. GET(acept=[‘html’,’xml’])

Wildcard content type matching also works. e.g. `text/*`

Note

Content negotiation within restish also honours the clients accept-quality scores. e.g. if a client sends `text/html;q=0.4,text/plain;q=0.5` text/plain will be preferred. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

We sometimes want to match lists of content types, for example where we would like to use `application/xhtml+xml`. This are honoured by restish. (See test_resource.py in the unit tests for examples)

### Navigation

- index
- modules |
- next |
- previous |
- Restish v0.5 documentation »