Recently, twitter blocked several applications citing violation of terms & agreements and copyright infringements. Well, this post is not to discuss if twitter did the right thing or wrong. I would like to highlight a subtle point to other API providers instead.
Thanks to the recent mobile revolution, apps are the defacto mechanism to make your content/service available on the mobile. And apps need to talk to your APIs to make this happen. APIs are the integral part of this revolution. If your company has a website and is providing some service/content and is not already providing an API, following are some resources that may help you to understand the ecosystem. Google should help you in finding lot more resources…
- API Evengelist – Wiki on the APIs and the ecosystem.
- Programmable Web – A director of APIs
- apigee.com, mashery.com – check out the whitepapers and blogs. Note that much of this is not vendor biased content.
These days, exposing a REST API is fairly a simple task. Whether you are a java developer, ruby developer, python developer, php developer or a javascript developer, there are lot of frameworks and libraries that will help you get started with API development and go to production in no time (May be topic for another blog post). Good thing is that you can focus on your key business aspect and reduce your time to production significantly.
Unless you are a pro and have done this sort of thing in the past, you will soon realize that you need to do lot more cross-cutting stuff on top of taking the API to production. For example, you find that few app developers are violating the terms and contracts they agreed to and you need to stop them from using the API – much like what happened in the case of twitter. A simple IP based access control is not going to help you because unlike website consumers, apps are installed on mobiles and traffic could be coming directly off of these devices. But you cannot block this IP because it is not the end user(consumer) who is violating the terms (in this example), but the app developer – so you need to block the app, no matter which consumer is using it.
Many questions will be coming across your way and you were not prepared to answer. For example, some usage related questions are:
- Which are the top API calls in my service ?
- Can we look at the usage on per-app and per-consumer basis ?
- Can we limit the usage of an app or consumer instead of blocking them altogether when terms are violated ?
- How do we ensure that a single app or consumer traffic oesn’t load the server ?
- Can we expose the usage information to app developers ?
There will be several other questions relatad to security, versioning, monitoring, visibility and analytics. You can read about them in the links above. The usual choices are build Vs buy. Clearly, there is lot of stuff to build if you choose to go that way. API Management systems are perfect if you are instead looking at a 3rd party solution. Good thing about many of these API management systems is that you donot need to make any changes to your API or code. They sit in front of your API server much like a load-balancer and give you all the control and flexibility we talked about.
Whether your API is on-premise, hosted in cloud or you are just looking for a SaaS like solution, you will find a vendor providing that solution. So, do some home work, choose the right solution matching your needs.
Here are some API Management vendors that I am aware of:
Disclaimer: I worked for apigee at one point and the intention of this post is not to promote any specific vendor.