This brings up an interesting point, and an ongoing conversation we’ve been having for almost three years now. I usually describe an API as having two parts:

1. the domain-specific stuff that actually IS the API (which is usually the same set of services that power a company’s own website, or that have been previously made available privately to other partners for ‘integration’); and

2. the management layer, that does things like key issuance, self-provisioning, rate limiting, throttling, method usage rule enforcement, reporting, etc.

Clay and the rest of the team at Mashery have done a great job in building a system that in almost all cases can do everything necessary for #2 without needing to make modifications to #1. It turns out that the set of services needed for #2, if done right, are independent of what #1 is doing and how it’s architected. So the same multi-tenant system that runs Netflix’s API can also run Best Buy’s and the New York Times’s.

In Mashery’s early days, we considered an approach that would try to “normalize” API calls across services providing similar capabilities, but quickly rejected that as a “lowest common denominator” approach. That was the right decision, and after nearly three years of development and dozens of implementations we have created a system that has immense flexibility – but is still very straightforward to implement.

Cheers -

Oren Michels
Co-Founder & CEO
Mashery

Cornelius.

Thanks for the mention!

Just to clarify, Mashery’s services have been designed from the very beginning to be 100% transparent. No code modifications or “binding” of any kind is required to leverage the Mashery solution. Some configuration steps during implementation through our management dashboard and a bit of DNS fu, and you’re up and running under Mashery.

Best,
Clay Loveless
Mashery Co-founder and Chief Architect