Question

Ok so I have my apps, that takes requests from root / Almost everything is using traversal.

But i’d like to make on top of that site a rest api.

So I’m off with two choices. I either separate the that in two different apps and put that rest application to : rest.site.com, Or I can move it to site.com/rest/*traversal

If I’m doing “/rest/*traversal”, I guess I’ll have to add a route called rest_traversal where the traversal path will be *traversal with the route /rest/*traversal. I did that once for an admin page.

I was wondering if there was a cleanest way to do that. I tried to use virtual_root, but as I understand virtual_root is actually getting added to the path for traversal.

like having virtual_root = /cms and requesting /fun will create the following path /cms/fun

I on the other hand wish to have /cms/fun turned into /fun

Answer 1

If you’re using traversal already, why not just use it to return your “rest API root” object when Pyramid traverses to /rest/? From there, everything will work naturally.

class ApplicationRoot(object):

    def __getitem__(self, name):
        if name == "rest":
            return RestAPIRoot(parent=self, name=name)
        ...

If your “application tree” and “API tree” have the same children and you want to have different views registered for them depending on which branch of the tree the child is located in, you can use containment view predicate to register your API views, so they will only match when the child is inside the “API branch”:

containment

This value should be a reference to a Python class or interface that a
parent object in the context resource’s lineage must provide in order
for this view to be found and called. The resources in your resource
tree must be “location-aware” to use this feature.

If containment is not supplied, the interfaces and classes in the
lineage are not considered when deciding whether or not to invoke the
view callable.

Another approach would be not to build a separate “API tree” but to use your “main” application’s “URI-space” as RESTful API. The only problem with this is that GET and possibly POST request methods are already “taken” on your resources and mapped to your “normal” views which return HTML or consume HTTP form POSTs. There are numerous ways to work around this:

• register the API views with a separate name, so, say GET /users/123 would return HTML and GET /users/123/json would return a JSON object. Similarly, POST /users/123 would expect HTTP form to be posted and POST /users/123/json would expect JSON. A nice thing about this approach is that you can easily add, say, an XML serializer at GET /users/123/xml.

• use custom view predicates so GET /users/123 and GET /users/123?format=json are routed to different views. Actually, there’s a built-in request_param predicate for that since Pyramid 1.2

• use xhr predicate to differentiate requests based on HTTP_X_REQUESTED_WITH header or accept predicate to differentiate on HTTP_ACCEPT header