4 ms·

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 t

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.

ljd 14y ago
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.

ljd 14y ago

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.