Enterprise Integration Zone is brought to you in partnership with:

Fredrik Håård is a partner and specialist at Softhouse Consulting as well as co-founder and head developer at Visual Units, a Swedish company creating support tools for logistics. Fredrik is a DZone MVB and is not an employee of DZone and has posted 21 posts at DZone. You can read more from them at their website. View Full User Profile

pyRest part 2: Hooking the API

12.24.2012
| 1886 views |
  • submit to reddit
In part 1, a very unexciting base CherryPy implementation was all we had, but now it's time to hook up something real! Instead of creating a mock API to work against as example code, I've decided to use hgapi to access the pyrest repo itself as example implementation - very meta!

I've decided to hook the API in before I refactor the code to separate the web framework from pyRest, since I firmly belive in getting things working first and cleaning up after. I did create a namedtuple to hold basic response values so that the requesthandler function can be extracted later.

The 'interesting' part looks like this
Response = namedtuple('response', 'status content')
def requesthandler(method, *pathargs, **kwargs):
    """Main dispatch for calls to PyRest; no framework specific
    code to be present after this point"""
    if not method == 'get':
        return Response('500 Server Error', 'Not implemented')
    repo = hgapi.Repo('.')
    return Response('200 Ok', repo.hg_id())

..not much yet, but it responds to any GET request with the current Mercurial node id.

My intention is that the final result will be three separate parts - a routing/domain specific part that uses hgapi, pyRest proper which handles requests and autohooks up the routing, a CherryPy part which integrates with CherryPy and will need to be reimplemented for every web framework supported.

That will be at at least one update before that though, because next will be "autowiring" the routing logic. Code for the project is available at Bitbucket

Published at DZone with permission of Fredrik Håård, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)