The author left out the most important part, which is the controller. The HTTP methods match controller verbs without requiring any attribute markup. The Get method responds to /controller (all) or /controller/5 (ID of 5), the Post method responds to a POST on /controller, the Delete method responds to DELETE on /controller/5, etc.

It's very elegant at this level. Adding additional methods requires more work, as does managing routing and the other support infrastructure in a more complex application, but it provides a great starting point.

One of the things that isn't great is that they, of necessity, have a different base class. Instead of Controller, it's ApiController. That makes sense. However, the differences pervade the entire stack, down to things like the Request and Response objects, and even AuthorizeAttribute (same class name in a different namespace with different parameters).

All in all, though, it's great. It certainly beats using WCF for simple REST APIs and it beats trying to repurpose MVC to implement an API.

Still a lot more bloat in web api than nancy