The motivation for creating this library was pretty simple: I really like the Rails way of modeling the application around resources, and then ’mounting’ those resources at URLs with the absolute minimum necessary amount of code. This resource-oriented approach is key in building truly ‘RESTful’ web services.
I wanted a simple but powerful content negotiation mechanism, which effectively gave me a comprehensive ‘API’ with zero additional effort. I think I’ve achieved that here; for example, adding JSON output support to a specific action is usually a 3-line affair, or you could very easily write a generic renderer and enable it for all actions across your entire site.
Finally, even though the Rails inspiration was so strong, I needed to keep Dagny as consistent as possible with the practices and idioms of the Python and Django communities. Again, I think I’ve done pretty well in that regard.
In response to your other question, I think Piston is a great library—however, I think the idea that you have to define an API separately from the rest of your site is just the wrong way to do things. I’m also not a big fan of Piston’s architecture and resulting API; it’s not as polished as I’d like it to be (although that’s more of a cosmetic issue).