Monday, April 13, 2015

The API First Manifesto

With the UK elections coming up, and the US 2016 election gaining momentum, manifestos are in the news. In the API world, we also see the API First approach similarly gathering momentum. I recently had a good discussion with Alex Sword of CBR about what "API First" means. It's part of a larger article about security and devices. Here are the three recommendations I picked out in the article about API First:

1. Treat your API like a first-class citizen of your architecture
This is something which Accenture's Kevin Kohut has spoken about at Axway's API Workshop events and at our US Connections customer event. Kevin recommended treating an API like a product, with a name, a roadmap, and a designated product manager. Having someone whose responsibility it is to manage the API is important, because it reduces the risks that the API will be changed in a way which breaks existing client usage.

2. Build the API first, not as an afterthought as part of a mobile app project
API First means literally building the API first. All too often, ad hoc APIs are built just to get data to and from a mobile app, which is built first ("mobile first"). These ad hoc APIs can multiply and become a nightmare to manage. If you built the API first, and manage it as a product (see Recommendation 1 above), then when your mobile app developers need to access data then they can be directed to use the API.

3. Don't tie your API only to mobile
Another way API First is different from "mobile first" is that when you design your API first, you can design it in a client-neutral manner. This means that it's not only for mobile clients. APIs have traditionally been associated with mobile, but now we're seeing other types of clients, such sensors and wearable devices, come to the fore. By all means, you can design "Experience APIs" in front of the core API layer, to tailor the API UX to specific types of clients (e.g. adding pagination for mobile clients). But, the underlying API is designed first: another example of "API First".

Check out the whole article here:

And contact Axway if you'd like an API First shirt :-)

Monday, April 6, 2015

Top 10 API Security Considerations - Gunnar Peterson White Paper now available

Last year I co-presented a webinar with Gunnar Peterson on the Top Ten API Security Considerations (you can view the API Security webinar recording here). Gunnar has now written a follow-up API Security White Paper which you can now download from the Axway website.

Gunnar has written a blog post about the API Security White Paper in which he notes "I see a lot of people rolling out APIs without a ton of thought given to the security fundamentals", and I agree. He explains that: "This paper is designed to help you build a model that works to protect your APIs." Click the image below to get the White Paper (short registration required):

API Workshop - Axway and Versent in Sydney and Melbourne

Our API Workshop world tour rolls on: Last week in Australia, we ran a series of API Workshops where our Axway partner Versent spoke about API strategy and security. Versent are experts in digital strategy and Cloud. Here is a photo of Evan McLean from Versent in action onstage, explaining the auto-scaling of API Management in the Cloud:

If you're based in the US, you can catch our next API Workshops at the Axway Innovation Forums in Philadelphia on May 5Chicago on May 12, and San Francisco on May 19,

Thursday, April 2, 2015

White Paper with Ben Kepes - "10 Best Practices for Thriving in the API World"

Top 10 lists are all the rage these days. I blame Buzzfeed. We've all seen titles like "Top Ten reasons why this incredible thing is incredible - you won't believe number 7!!!!"

But, I hope that in the case of the white paper which I'm privileged to have co-written with Forbes' Ben Kepes on "10 Best Practices for Thriving in the API World", I hope the Top 10 is more sober and useful. Take Best Practice number 3: "Use a Common API Layer to Ground the Cloud":
This idea of a buffer layer extends beyond applications; infrastructure elements,
communication channels, mobile devices, application components and sensor inputs
are all examples where interplay between on-premise resources and the outside world
often needs to occur. The key is to find a buffer layer that bridges the gap between the
inside world and the outside. This requires solutions that turn existing systems into
broadly consumable APIs (and also solutions that do the reverse). 
While many people think that a successful API strategy rests on moving everything to
the cloud, or at least to new architectures, the reality is different. On-premise is not
going away for many good reasons. Instead, you should focus on wrapping applications
in an API-enabling layer that allows them to readily talk to the outside world while still
running on traditional infrastructure and architectures.
You can snag your copy of the white paper on the Axway site. And don't worry, it's one document and not a ten-page pageview-maximizing "Click for the next one" list :)

Wednesday, April 1, 2015

Amazon Dash shows the continued value of APIs to Amazon

It's well known that one of the keys to Amazon's success has been its APIs. Kin Lane has pointed out Amazon's internal APIs, which were famously driven by a directive from Jeff Bezos himself. And, of course, Amazon Web Services (AWS) is fully API-driven, which allows for full automation. Just this week, the Boston Globe covered the fact that Jeff Bezos has been advising iRobot, and it was no surprise to read that "one of the key pieces of advice Bezos supplied was about the value of open APIs".

Even more recently, Amazon has released the "Dash Replenishment Service" (DRS). Although I'm writing this post on April Fools Day, it was released yesterday so I think I can confidently say it's not an April Fool :-). Dash will allow customers to re-order stocks of items such as paper towels, simply by pressing a physical button. Amazon has launch partners for Dash, but of course they don't want to limit DRS to just these items. The key is an API. An API would allow other products to be integrated into DRS. So, the first thing I looked for under the DRS announcement was their API. And, sure enough, I found this:
Can we really implement DRS with 10 lines of code?
Yes. Device makers can start using DRS with as few as 10 lines of code using simple HTML containers and REST API calls. Device makers can place orders on behalf of their customers without having to manage addresses, payment instruments, or billing systems.
It's always advisable not to bet against Amazon. APIs are a big reason for this. With DRS, we see the value of APIs again.