njyx

ok - so someone downvoted my comment here.. nice. :)

Good luck Swift - I'm sure you'll do great things. That is indeed a heck of a scaling problem!

Hi Xorlev - nothing is beyond improvement but we normally get excellent feedback from customers - and at very high volumes and performance! Having said that if you're having / issues problems then definitely contact us and we'd be happy to help.

More coverage here too: http://gigaom.com/2013/04/24/3scale-gets-4-2m-to-help-compan...

it was interesting that when we tried to pull together the best blog posts on APIs across the web this year (http://www.3scale.net/2012/12/top-10-api-blog-posts-2012/) the strongest theme was exactly about this - the push and pull of private data and platforms.

It's a lot of white-label Fabs, so manufacturers can take the blueprints, tweak and then do their own runs. I think the author's comparison is spot on - the ARM model is actually a killer advantage. It will actually shrink the value of the market while pushing the volumes through the roof. That sounds like a crazy thing to do - unless you're the one in control of the show.

Except that's exactly not what's going to happen - the shift is determinedly away from heavy desktop apps to lightweight clients and more work done on the server backend. That causes a dramatic split in processing needs: clients get thin (requirements flatline in procesing) and servers get fat (now all the work is server side). What used to be a "unified" market suddenly is not any more.

The number of units sold is capped by the market size. If someone else is selling $1 devices and you are selling $10 but the $1 device meets the need, you won't be selling much. Microsoft/Intel might bank on those markets being "distinct" - but that's getting more tenuous each year.

The markets compact over time and $1 devices will kill $10 devices.

Also see API Evangelist: http://www.apievangelist.com

See also interesting: http://ryanlunka.wordpress.com/2012/12/04/death-of-the-web-b...

The site looks cool and interesting posts = but are you looking for technical detail analysis or stuff on trends to consider when building systems? (Example of the later because we just wrote it: http://www.3scale.net/2012/12/the-death-of-the-web-page/)

Some thoughts on why a legal precedent probably isn't enough: http://www.3scale.net/2012/11/the-case-against-api-copyright...

Response to the EFF appeal here: https://www.eff.org/deeplinks/2012/11/no-copyrights-apis-hel...

The original article is here: http://allthingsd.com/20121001/mashery-is-the-latest-to-be-s...

The chilling effect of going after service providers is really beyond the pale. ISPs are protected for good reason - the API layer shouldn't be different.

We use Swagger at 3scale - awesome framework and great to see more automation - a better kind of glue!

Free API Infrastructure is definitely a cool thing and we've been doing it from day one - our thoughts here http://bit.ly/OY7mLN :). Welcome to the party Apigee!

Not quite the same point - but similar thoughts: http://bit.ly/N9HnAD. What's really missing is a proper service contract. Not giving guarantees - or at best implicit ones will kill ecosystems.

Agree - and this is where technology really erases some of the fences that existed by accident when things were not so connected.

Worse, some people may end up with this knowledge and others not.

The infrastructure handles rate limits, access keys, analytics, dev portal, billing etc. for the API but does it out of band. So yes, the traffic does go to the API origin and then control agents there enforce the policies, do the tracking etc. (indeed a bit like New Relic).

It's used for some very big APIs but yes, the origin sees the traffic. The system can offload it though - there are agents for Varnish for example which you can sit in front of the app or integration with Akamai, in which case policies are enforced at CDN edge nodes.

If the API is handling high volumes you still have to plan for that - but the point here is that the management elements scale with it. You're not stuck with a black box in front of the API which might blow up at inconvenient moments.

True - although you can get pretty good approximations. Still though, the point is valid: it would be very expensive to guarantee. Performance profile could drop badly pretty much any time.

Isn't there a way to get guaranteed bandwidth / throughput / speed from both parties in this? Not that compression isn't great but this seems to upper-bound pretty much anything.

3scale (http://www.3scale.net) uses Swagger to do this out of the box on all of it's API portals. Swagger (see http://swagger.wordnik.com) gives you live docs but also tools to mark up the code to rip out the specs when you update code.

I guess it's just because of Facebook - but still, that really sucks.

Wow - looks like pretty soon there wont be any bridges between ecosystems.

I'm from 3scale - so factor in any bias filters!) - we definitely think of it as a contract between the provider and user of the API - could be very lightweight or heavyweight - but basically it's a bunch of rights on the API v's a promise of good behavior.

Actually a lot of the APIs that use us are B2B because you often have different tiers of access rights and limits + want to have approval steps etc. for sign-ups. These are pain to code yourself.

The change part is a big deal - we normally deal with it in two ways: 1) launching parallel services for major versions so people consciously migrate their apps, 2) incremental updates - docs are versioned but all the same calls work on the same endpoint. How the version is flagged in the call is rather independent (URL, header, type).

We also use the swagger docs framework (http://swagger.wordnik.com) to create interactive docs to try keep questions on the API itself to a minimum (people can play with it themselves).

Very cool :). If it doesn't make sense to monetize it might still at some point make sense to put sanity limits on some usage - otherwise some high volume users could end up making you take it down for cost reasons.

Nice problem to have though.

The github repo with code is here: https://github.com/3scale/sentiment-api-example

Kudos that they're the new team is getting user feedback. One thing that would be sad to loose is the API - it was one of the first back in 2007.

I like the "create more value than you capture" - I wonder how many companies genuinely think like that though. Wonder if Apple genuinely thinks about it like that.