(part 1, part 2, part 3, part 4)
I’m almost done with the parts to make this project PyPI ready - it can now work on your application as long as you implement the actual code to route calls to the right part of your API - this works:
python -m pyrest.launcher –server pyrest.integration.cherry \ –api=pyrest.examples.hg Configuration can also be done using a config file instead of or together with command-line arguments.
(part 1, part 2, part 3)
I’ve now split the code into separate parts - pyrest.py now only has generic functionality for hooking and routing, along with a bunch of helpers to create responses with HTTP response types. In fact, it’s only 35 lines of code, and that’s the entire ‘core’ of pyRest so far.
The CherryPy integration has moved to the pyrest.integration package as cherry.py - it’s still pretty clumsy to use (python -m pyrest.
In part 2, I hooked up the API to CherryPy in a very crude fashion, and this time we’ll look at how we can add handlers for resources in a less clumsy way. I decided to keep handlers on one ‘level’ only - that is, /sketch/parrot and sketch will both be handled by the /sketch handler. This is because I find that the same sub-resource often is present in several places (what about //props/parrot?
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.
After having written code to expose APIs through RESTful web services a couple of times, I’ve decided to do it once more, only this time I won’t get paid, I won’t have deadlines, I’ll write it so I’ll never have to write it again, and I’ll make it available as open source.
Problem is, I’m a lazy, lazy person, and have not been able to muster the energy to actually get writing, which leads me to this blog post - since I’ve not been updating the blog as I should either, I’ll kill two projects with one meeting and make the actual development process open as well, as a series of blog posts and a repository at BitBucket.
Edit: got complaints that code was hard to read, trying out Pygments.
In part 1, we looked at sending functions as arguments to other functions, at nesting functinons, and finally we wrapped a function in another function. We’ll begin this part by giving an example implementation on the exercise I gave in part 1:
>>> def print_call(fn): … def fn_wrap(*args, **kwargs): … print("Calling %s with arguments: \n\targs: %s\n\tkwargs:%s" % ( .
I’ll be appearing att Software Passion to speak about using Python for protocol specifications, instead of using an external document to write the specification, and then try to implement it from there (or, perhaps more common, implementing it and then trying to keep the document up-to-date).
A while ago at Visual Units, the situation was this: There was a protocol to transfer data over TCP from fleet management black boxes running J2ME to a server running Python, which then stored that data so interesting things could be done with it.