Creative Commons Attribution-Share Alike 3.0 United States License
== ED ==at 6 apart when opening the API: New UI Paradigm - continuous scrolling vs the page load paradigm. 1 to 2 orders of magnitude more content. * you wouldn't have predicted it - new reader application launched on TechCrunch
There is a big difference between running a prototype and running a big API product.
In the world of web products there’s variation in browsers. And they can be super wonky. But nowadays those variations are known and predictable.We control everything else. And importantly we control all the code that calls our servers.SAM: trivial complexity because it’s homogenous. There’s variety but the complexity is trivial. You can rely on :BroadbandPC CPUs
In the API world we control much less. The variation is much greater. And we can predict very little.Importantly, we don’t control any of the code that hits our servers.
CC photoshttp://www.flickr.com/photos/peopleforcherry/3427058289/ http://www.flickr.com/photos/ifmuth/606128545/If running a big web product is like running a big building then running an API is like running a city. Building/Web: linear, rational, predictable. It’s about the technology.City/API: non linear, irrational, unpredictable, its about the people.SAM: Chaos is another way of thinking about complexityFirst responsersJitters in the systemDifferent patterns of behaviourHard to predict
What drives complexity?
The first driver is going from direct to indirect
This is totally different than the web and very complex:track our usersTrack the relationships between the apps, developers and our usersThis isn’t just password resetThis is authorizing on behalf of the user which parts of their data that we store that the apps can use
What does this mean in terms of scaling up requests and responses?Between any two requests the user might revoke privileges from the appSo we must check every response against the wishes of our users. OAuth increases the number of API calls necessary to get a new client up and running on the API, although if your API is successful then that will average out to not too much. OAuth also means that you have a whole bunch of tokens to maintain -- one per end user, per device, per app -- for a big API that's easily millions. You need them to be available at all times, and in fact you need to be able to write to that database at all times, not just read from it, so that you can issue new tokens whenever new end users appear or whenever they get a new device. So that's a lot of tokens. We're finding that databases like Cassandra and Riak that are eventually consistent and let you write from anywhere are much more effective for this problem than databases that rely on master-slave replication.ED: you’ll be using muscles you’ve never had to use before.
Bad developersDevelopers in a hurryOur API is not clear to themClient-side cachingiOS has restkit which uses Core Data to store data locallyAndroid has restlet for caching and some folks use squid on the client side as a reverse proxy
Your API docs might be unclearYou might not be offering guidance on best practicesAPI design might be terribleBut if we do the above correct there are still 2 key considerations:Publish SDK/Libraries or not?With an SDK you can package up your API usage best practices that developers will adoptBut it’s a lot more work: you are now in the software distribution business. At least follow the OSS model: githubetcThe big dog debate: resource-oriented API design or UI-oriented “shortcut” API designProbably do both: resource first as the baseline, then shortcuts as needed by UI
You have to version
Innovation happens on someone else’s schedule and not yours.
Huge: Running an API at Scale
HUGE:Running an API at ScaleSam Ramji@sramjiBrian Pagano@brianpaganoEd Anuff@edanuff Apigee @apigee