API First

I missed Catalyst this year by being at the simultaneous Gartner AADI event in Sydney. But Eric Knipp has produced a great roundup of some key Catalyst ideas. In particular he says:

I’ve advised for some time that clients consider a Web API as the first step of a mobile development initiative, in particularly one that depends on connections to existing back-end systems that have not yet been ‘mobile enabled’. My conversations at Catalyst make clear that practitioners have come to this conclusion as well and are embarking on a variety of Web API initiatives in support of mobile app enablement. I have one further piece of advice beyond establishing a Web API at the outset of a mobile app initiative – don’t treat it as just a part of or infrastructure for your mobile app, but as a product in its own right.
http://blogs.gartner.com/eric-knipp/2012/08/27/catalyst-debrief/

This is what it means to be "API First". Being "API First" is not only about literally creating the API first, as the first step of a mobile initiative. It's also about having the API as a first class citizen in your infrastructure, a "product in its own right". So it's not only about developing the API first, it's also about putting the API first. Eric goes on to make some great points about versioning of the API, which means taking seriously the fact that developers depend on your API and will be thrown by any versioning confusion. If you put the API first, you will be less likely to make these changes, than the situation where the API is just an addendum to a larger chunk of infrastructure.

I look forward to more insights from Eric on this. It certainly is an exciting time to be in the API Server business.

Dell requires a SOA Architect with Vordel and Fiorano skills in West Virginia - Secret clearance required

Dell is looking for a SOA Architect with Vordel and Fiorano skills in Kearneysville, West Virginia. This position requires US Citizenship and the ability to obtain a DOD Secret clearance. All the details are below:

http://jobs.dell.com/west-virginia/engineering/jobid2694596-soa-architect-jobs

Parameterized URLs for REST APIs

For REST APIs, it's common to use URLs in the form:

http://api.mycompany.com/BillingAPI/{CustomerID}/99.99

In this example, we have a REST API to bill a customer, and the customer ID is passed inside the URL itself. This adheres more closely to the principles of REST, compared to using QueryString parameters.

Parameterized URLs are handled very simply in the Vordel API Server. Let's take the example above, where you are interested in the value of CustomerID within the path. You can get at this value using our selector syntax: ${http.path["2"]} . Using ${http.path["2"]} in any filter gets you the value of the CustomerID portion of the URL. Of course, in the example above, ${http.path["1"]} would get you "BillingAPI" and ${http.path["3"]} would get you "99.99".

Once you get the CustomerID via the selector syntax, you have all the power of Policy Studio at your disposal. You can use this CustomerID value to, for example, use the "Retrieve from or write to database" filter to read dynamically read customer information from the database, or the "Retrieve from Directory Server" filter to dynamically read customer information from an LDAP directory, using the REST parameter you've read in.

OAuth, API Portal, REST-to-SOAP, and XML-to-JSON at the Vordel API Workshop in Sydney

The Vordel API workshop in Sydney today was very well attended, with lots of great questions and discussion about Cloud, APIs, and identity. Attendees saw how to mash up APIs, how to convert REST to SOAP, how to convert XML to JSON, and saw API Analytics in action.

We also saw an example of an API Portal powered by the Vordel API Server, issuing API Keys and enabling developer self-service. We walked through OAuth architecture, and saw OAuth in action with the Vordel API Server. All in all a very productive session.

Pics below:

APIs come to the supermarket

There has been a rush lately of retailers exposing APIs to enable mobile access to what previously were in-store operations. Last month, Adam Broitman wrote in Advertising Age about Walgreen's photo API. In the article he notes that APIs may become crucial to brick and mortar stores. In the same trend, this month  Adam DuVander has written on ProgrammableWeb about how the Safeway subsidiary, Blackhawk Network, uses APIs for supermarket gift cards. APIs can sometimes seem like abstract things, to a non-developer (Adam Broitman writes "Take a trip to a few local drug stores and ask the pharmacists to define the acronym API. Chances are they won't know"). But, as Adam DuVander titles his article, the Safeway/Blackhawk gift card API is literally an example of an "API in the checkout line".

Safeway and Walgreens are both benefiting from their APIs to extend their businesses beyond the bricks and mortar world. The key driver is mobile. Take the gift card example: supermarket gift cards used to be solely physical cards. But mobile wallets change that. Adam notes that "Mobile wallets have extended what it means to distribute cards. Now, in addition to being a piece of plastic, gift cards also can live in a virtual collection that can react to our mobile lives"

Security remains important because supermarket Gift cards are tied to actual money. As Adam notes, "Naturally, security is a concern, so Blackhawk turned to Vordel for API management using a certificate-based model". If you want to find out more about how Vordel is used to manage Safeway/Blackhawk's APIs, here is a video which includes details on the management security provided by Vordel for the APIs.

The trend for supermarket APIs, driven by mobile, is one which is bound to just grow and grow. Front-runners like Safeway/Blackhawk and Walgreens are just the tip of the iceberg. 

Vordel workshop in Sydney next Friday - Cloud, Mobile, OAuth

I'm presenting a Vordel workshop next Friday in Sydney at the Sheraton on the Park. I'll be covering OAuth, showing how Mobile apps call APIs (using an Android client), how to convert SOAP to REST, and XML to JSON. All using the Vordel API Server. Register and come along, it's free :-) 

Cloud debate - Network World

I'm quoted in this Network World article about the recent hoopla about Steve Wozniak's comments on the Cloud. It's hard to get a lot across in a short quote, but I do believe that the broker pattern allows for businesses to reduce lock-in to any single cloud vendor, and to control what data is sent to Cloud services and what data is not.

Enterprise APIs and Public APIs

Over at APIEvangelist.com, Kin Lane has a great list of "Successful APIs to look at when planning your API". These include Ebay and Flickr. It's a great list, showing how APIs can be very different from each other. Some are OData-y (Ebay), some still support SOAP as well as REST (e.g. Amazon), and some are closer to REST Nirvana than others [if you want to make a RESTafarian's head explode, show them Flickr's delete operation which uses a POST.].

But one thing all these APIs have in common is that information about them is publicly available, to anyone, and anyone with the right credentials can use them. APIs which are used inside organizations, or within groups of trading partners, are not mentioned. At the Cloud Identity Summit last month, Anand Sharma ‏ from Cisco called these "Dark API's". The analogy is with Dark Matter. It's all around us, but we can't see it. Organizations are using enterprise APIs, which the outside world may not know about. Same goes for APIs used within products. I've written before, back in 2009, about why there isn't a Pandora API. Fast forward to 2012 and Pandora still doesn't have a public API. It doesn't fit their business model to have one [something that's worth a whole blog post in its own right]. But you can bet Pandora has their own API definitions they use internally. Effectively, that's a "dark API" too, even though it's for an entertainment service. So the distinction is not about "Enterprise versus Consumer" anymore (echoes of Eve Maler's excellent OAuth 2 piece)

For many of Vordel's API Server customers in the healthcare and financial transactions sectors, it doesn't make sense to have a "Public API". But they still want to leverage the benefits of APIs (e.g. for a HMO to talk to its hospitals). Eric Knipp from Gartner has been doing some really good research on this, about the distinction between "Public APIs" and "Enterprise APIs". Whatever terms we end up using ("Dark APIs", "Enterprise APIs"), it's definitely a conversation worth exploring. 

Tip: Reducing the size of a Linux VMware image

Here's a handy tip I'm blogging for reference. You can make a Linux VMware image zip smaller by zero-ing out unused space and then running the "Compact" utility in VMware. The command to zero-out the space is:

sudo dd if=/dev/zero of=/home/user/wipe.file
rm wipe.file