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.
In other words, what makes a good API MVP that doesn't get launched only to have to deprecate stuff soon after?
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.
If it helps, I can share a bit about that. Our API has gone from several hundred hits to several million, while its no Twitter API we are closing out our "0 - 1" phase as Peter Thiel would put it.
Probably the most important thing for a builder of a B2B API like ours to consider is that someone is requiring (read: forcing) another developer to integrate your product. Counterintuitively, you will probably get more push back from tech teams than from the business side. I understand their reasoning, I've been a software architect for many years and often had to figure out how to delicately stretch technical resources to attack what seems like a constant onslaught of new requests. How did we solve this problem? We created a GitHub account, built wrappers around our REST calls for Python, Ruby, Java, PHP and C#. Our whole goals was to create copy and paste code. Technical pushback has gone way down.
Another important lesson that they touch on is simplicity. Don't be creative or try to show how out of the box you can be on picking resource nouns. Accepting product information? Please use apiurl/Products/id. A notable mark of mastery isn't how complicated you can make something, it's how simple you can express it.
Are Enterprises so lazy to build an API around their data models?
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.
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.
6 comments
[ 5.6 ms ] story [ 34.1 ms ] threadIn other words, what makes a good API MVP that doesn't get launched only to have to deprecate stuff soon after?
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.
Probably the most important thing for a builder of a B2B API like ours to consider is that someone is requiring (read: forcing) another developer to integrate your product. Counterintuitively, you will probably get more push back from tech teams than from the business side. I understand their reasoning, I've been a software architect for many years and often had to figure out how to delicately stretch technical resources to attack what seems like a constant onslaught of new requests. How did we solve this problem? We created a GitHub account, built wrappers around our REST calls for Python, Ruby, Java, PHP and C#. Our whole goals was to create copy and paste code. Technical pushback has gone way down.
Another important lesson that they touch on is simplicity. Don't be creative or try to show how out of the box you can be on picking resource nouns. Accepting product information? Please use apiurl/Products/id. A notable mark of mastery isn't how complicated you can make something, it's how simple you can express it.
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.
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?