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