Pathod: A pathological HTTP daemon for testing and torturing client software

Drat - this story is just a tad premature. A brand new release of pathod will be out next week, including a publicly accessible pathod instance, pathoc (pathod's evil client-side equivalent), and a huge range of other improvements and bugfixes.

This is a similar tool as <a href="http://httpbin.org/" rel="nofollow">http://httpbin.org/</a> which was written by Kenneth Reitz to test python request <a href="http://python-requests.org/" rel="nofollow">http://python-requests.org/</a>. I like that this is written in tornado thanks for sharing.

bane is a similar tool that pathod-interested users might be interested in.<p><a href="https://github.com/danielwellman/bane" rel="nofollow">https://github.com/danielwellman/bane</a><p>From the readme: "If you are building an application, you may depend on third-party servers or web services for your data. Most of the time these services are reliable, but at some point they will behave in an unusual manner - such as connecting but never respond, sending data very slowly, or sending an unexpected response. To ensure your application survives these scenarios, you should test your application against these bad behaviors. Bane helps you recreate these scenarios by standing in for your third-party servers and responding in several nefarious ways."

Really cool!<p>A year or two ago, I was working on some automated deployment tools that basically called a bunch of Rest APIs. As I discovered how unreliable the API calls could be at times, I ended up writing something kind of similar (although very application-specific to this) to be used as part of my unit tests for it - it helped immensely.<p>One thing that would be nice is if I could pre-define reactions to certain requests - ie, some sort of way to specify that when you get a POST at uri /add with a content-type of application/json, I want a 500 error (or maybe I want a 500 error 5% of the time) - rather than having to specify what I want in the actual request. Is this something your client library will make possible?

I like the idea, but does the syntax have to be that terse? It's quite expressive but less readable than code (or JSON/YAML), and I'm not sure why that's useful in this context.

What's the practical usage scenario for this? Would it be only used by http client library developers, or is there a broader audience?