The guide seems to approach API design from the perspective of big players. It would have been nice to point out what to focus on first for fledgling services that want to take baby steps with the right foot. Rate limiting and metrics are way less important when you're happy someone is even using your API in the first place.<p>In other words, what makes a good API MVP that doesn't get launched only to have to deprecate stuff soon after?<p>I think that'd be a far more substantial contribution to the SaaS web, since there are far more people starting out or with no API at all than there are companies with pressing demands for a thorough service, and those can more easily have someone experienced on board anyways.
Are Enterprises so lazy to build an API around their data models?<p>I would like to see a detailed comparison of the framework API's(say in django, Tastypie) with 3rd party managed API's. Its a great read to see the pros and cons in this context.
Nice slidedeck for good APIs principles evangelisation
But nothing on Policy and Terms of Use which become the main issue for developers , before good design.
surprisingly little mention of the actual interfaces themselves (the API calls) and instead a lot of focus on the meat that goes on those bones.<p>Hanson's "C interfaces and implementations" has a lot of good stuff but some of it doesn't apply to modern APIs. anyone have a good reference that complements Hanson in the web API era?
A great API is one that is fully documented and doesn't hide any API calls. One that doesn't keep changing the API calls to make sure older programs break, but create newer API calls to do new things and keep the old ones for legacy support.