“It’s never been easier to construct an API, but running them and managing them has never been harder: devops, security, cloud,” said Ed Anuff, SVP product strategy for Apigee, the API management platform company, as he opened the I Love APIs conference in London this week.
"Scale is the starting point, and is what most people get wrong."
These sort of mistakes when implementing an application programming interface (API) strategy in the enterprise can be avoided with a little bit of forethought and by heeding the advice of companies that have been there, seen it and done it.
Here is some advice from the likes of Bupa, Marks and Spencer, Laterooms.com and Thomson Reuters on how to implement APIs across your business in the smoothest way possible.
“Each of our product teams owns an API and that's what they expose to all the other teams. Because of the way we have architected this with individual product teams they own the whole stack, we've been able to leverage new things and move away from SQL [server database].” - Andrew Braithwaite - solutions architect, Laterooms.com
Oliver Ogg from Marks and Spencer developed a specific team around APIs, but the downside of not owning the whole stack meant “we don’t always have the domain expertise in the team”.
2. Evangelise API usage
"One of the key things we do is educate and evangelise, and I underestimated how much time we spend on this. We do lots of workshops for API design and tooling. We do regular show and tells. Something I haven’t done enough of is publish about the consumer success of the various apps we have out there now running on our APIs.” - Oliver Ogg- product owner of APIs, Marks and Spencer
“Apigee means different things to different people. By showing stakeholders visual, analytic dashboards we were able to convince stakeholders that this was the best tool for what they need.” Dhanajay Tripathi - senior enterprise architect, Bupa
3. Keep the management layer simple
"We moved for a simpler, clearer layer of integration using the Apigee platform. We are not there yet completely, but I believe the industry as a whole is moving away from a complex layer of integration to a much cleaner, simpler layer of implementation.”
The advantage of this is that any security rules, business rules and aggregations “can happen at the native layer”. - Dhanajay Tripathi - senior enterprise architect, Bupa
4. Embrace the wider developer community
"We’ve got 15,000 people and hundreds of APIs internally. It’s not feasible for us to centralise all that API development."
"We don’t want to be the bottleneck stopping the organisation progressing. That’s why we chose this federated management model. What this means is teams bring their APIs to the platform and they do the work of getting it up and running. That’s one of the reasons we chose Apigee, because we felt it was a platform that would allow us to do that, it was going to allow us not to centralise.” - Ian Cooper - architect, Thomson Reuters
“Make it as easy as possible for API providers coming onto your platform to do the right thing, because otherwise it is going to be like the wild west. They’re going to go off and do all sorts of crazy stuff with this Swiss army knife technology that they’ve got which may not be appropriate. Once they’ve gone down that path, getting them back can be really difficult.” - Ian Cooper - architect, Thomson Reuters
"One regret I definitely have is not defining or having some guidelines around API design earlier. So as a team we kept things on a good trajectory and have got good consistency but as things have scaled out I wish we had spent some time defining what we think are our standards. This is really subjective stuff, but just having it up front would have been easier.” - Oliver Ogg - product owner of APIs, Marks and Spencer
6. Create solid documentation
“First off we provide what we call our API provider toolbox, so we spent quite a lot of time initially handholding teams and getting their APIs onto the platform, and through that we learned a lot about Apigee itself and how we wanted things to work. We took that information, we verified it and we put up a set of documentation that tells people how we hope they get APIs onto the platform.” - Ian Cooper - architect, Thomson Reuters
“We’ve been using Swagger for a while but we spent quite a lot of time making sure our documentation is consistent, not just in Swagger but in various git depositories as well. We provide lots of sample queries and code for us to help people along.” - Oliver Ogg - product owner of APIs, Marks and Spencer
7. Think about caching
“Caching is vital for us as third parties use our data and it’s all about speed. We cache in database, in the APIs, inside Apigee, so it’s difficult to work out which cache you need to expire and how long it should be valid for. Because it needs to be cached in five different places you think it could take 20 minutes but it could take 24 hours. That makes a massive difference to us because the prices could just be wrong.” - Andrew Braithwaite - solutions architect, Laterooms.com
8. Think about versioning
“APIs will change and the biggest mistake we made was we forgot that they will change, so when our original APIs were put in place they had nothing for versioning, so there was one URL per employee. So to change anything you had to go round to all of the client applications to say: 'We’re going to change the API, you guys need to get ready' - get everything lined up, do a deployment and everyone would be happy.
"There’s lots and lots of ways of versioning APIs, they’re all wrong, whichever way you choose to do it someone will hate it, they just will. So we chose in the end to do it in the URL, some people do it in headers, some people have different URLs completely. Just choose one, it doesn’t matter.” - Andrew Braithwaite - solutions architect, Laterooms.com
9. Log everything
“We’ve never regretted logging too much and in this landscape you really do want to log as much as possible.” - Oliver Ogg - product owner of APIs, Marks and Spencer