This is a nice take on the I/O Docs/API Explorer style (e.g. <a href="http://developer.mashery.com/iodocs" rel="nofollow">http://developer.mashery.com/iodocs</a>). Those sample JSON responses could really stand to get some pretty printing though. Don't provide example responses if they're unreadable. The post even touches on this ("An API’s documentation is its human interface") so it would nice to see them made more human-readable.
With the Scripted API, you can build a self-publishing website in < 50 lines of code. We're publishing to our own magazine sites using this API!<p>Basic flow:<p>Use a feed to parse and generate topics
Push blog article jobs to Scripted
Pull finished content from Scripted
Post content to your CMS<p>We'll write another blog post about it in a couple of weeks.
The Redis docs are similar, albeit not quite as fancy. The reference page for each command includes a few example requests and their results -- and it's connected to a running Redis server, so you can actually type commands into it. Check it out:<p><a href="http://redis.io/commands/sadd" rel="nofollow">http://redis.io/commands/sadd</a>
There should be a rule that if you have to write a wrapper for the API, then it's either poorly designed or poorly document, or both. Eg PayPal, Google, LinkedIn.