Matthew Weier O'Phinney has posted the third part of his series about making RESTful APIs with Zend Framework 2 (parts one and two). In this latest part of the series, he talks more about documenting the API and what commands can be executed.

In this post, I'll be covering documenting your API -- techniques you can use to indicate what HTTP operations are allowed, as well as convey the full documentation on what endpoints are available, what they accept, and what you can expect them to return. [...] hy Document? If you're asking this question, you've either never consumed software, or your software is perfect and self-documenting. I frankly don't believe either one.

He covers a few reasons why you should document your API and where he thinks it should live to be the most useful. He includes a few different ideas and two things he definitely thinks should exist for your API - the use of OPTIONS and end-user documentation. The first is a HTTP header (ZF2 code example included) that tells the API consumer what they can do with an endpoint. The second type is more useful for the human reader, giving them a better overall perspective on what the API can do - still served through the API but in a bit more understandable format.