Blog post

Catalyst Debrief

By Eric Knipp | August 27, 2012 | 3 Comments

Web APIs

I just returned home to Dallas after participating in my first Gartner Catalyst conference. The event was impressive with tons of content and almost 1800 attendees on-site, not including Gartner staff. I’ve presented at a number of Gartner Symposia and Summit events and I was struck by the deep level of attendee engagement at Catalyst. Our attendees are in the midst of mobile, cloud, and big data initiatives and it was great to hear about their experiences and challenges in my conference sessions, roundtables, and of course copious analyst-attendee 1-1 sessions. As I cover Web APIs in depth these days (and to a lesser degree mobile development) I thought I would share my top 3 “aha” moments from the conference, based on attendee feedback and questions:

The mobile bone is connected to the Web API bone. 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. Done well, your Web API will power multiple mobile apps, partner integrations, and Web applications, but that requires a commitment to design that is easy to skip if you think you’re just doing it as a one-shot deal for a single app.

The majority of Web API initiatives leave versioning for later. I believe this is a dangerous idea for a variety of reasons. First and foremost, if you run just one version of an API you risk introducing a breaking change anytime you extend it. While you can potentially work around this with a very robust set of test cases (which I would strongly encourage), it is easy to paint yourself into a corner when you are unable to fix a bad implementation that seemed like a good idea at the time. Over time your code gets crufty and filled with technical debt and eventually you might be forced to declare bankruptcy – basically starting over with a new Web API and disenfranchising all of your existing API consumers all at once. On the flipside, versioning isn’t something you should automatically commit to. Running multiple versions has its own costs – multiple code bases and the overhead that comes with that, multiple groups of API consumers and the service levels you must provide them, and so on. My advice on this one is just to take it seriously – if you choose not to decide, you still have made a choice.

Consuming Web APIs from external providers can be a serious challenge. If you deal with a lot of niche players with screwball ideas about Web API design you have your work cut out for you. While the cloud and social leaders like Facebook,, Twitter and so on get a lot of pub for the quality of their Web API designs, there are myriad small SaaS providers who treat the Web API as an afterthought. Understandably, they instead spend their R&D dollars on slick GUIs and worthy business processes which the business selects without even considering integration. If you are unlucky enough to be asked to integrate some of these niche apps with your existing systems it isn’t going to be a lot of fun, especially if you use the brittle point-to-point style of integration. My advice is that you consider using a gateway to shield your applications from direct exposure to external Web APIs.. this will provide you a single logical layer to deal with and the better API gateways on the market can do some basic transformations and quality of service improvements that allow you to homogenize the interfaces somewhat, which can be very useful if you’re part of a larger team that delegates the business logic implementation to different hands than the actual service consumption/integration.

Web APIs are growing in popularity and that makes it a fun time to cover them. Web API gateways, servers, and management technologies are proliferating at the hands of cloud and product vendors alike. If you’re a Gartner for Technical Professionals client I would love to talk to you about it.

Comments are closed


  • Mark O'Neill says:

    Definitely agreed that an “API First” strategy makes sense for mobile. As you say, the Web API is the first step of a mobile development initiative. The API itself is the product, as far as a mobile developer is concerned. I like that you don’t specify what the underlying technology should be also. A well-designed API should be agnostic to this.

    On the next two points, I think unfortunately there can be an interplay between versioning and “brittle point to point integration”. Although there are some best practices for versioning of APIs (e.g. where to put the version info), opinions vary, and in the worst case, new versions risk breaking existing implementations. This is another case where it makes sense to shield yourself from direct exposure to external APIs, and instead use a product for a logical layer in between. This layer will handle different (aargh) versions of versioning.

  • Eric Knipp says:

    @Mark, thanks for the comment.

    I concur with you that enabling technology doesn’t matter from the Web API consumer’s point of view. All the consumer sees is the interface and support services/artifacts so you better be sure you do a great job there. As Web APIs proliferate, finding the right Web API will become a search problem (credit to Scott Regan at Apigee for this insight in a 1-1 conversation several years back), and if your Web API isn’t usable then it won’t get used very much.

    My point on versioning isn’t that you should or shouldn’t version, it is that you have to think about this concept up-front. I’ve spoken to a lot of practitioners who either didn’t think about versioning at all until they were in production for a period of time, or who did briefly think about it before deciding that it didn’t really matter all that much, so let’s just “ship it” and fix it later. It’s OK if you want to run a single version but beware of the tradeoffs that you are accepting and be sure that they fit your business model. I guess its probably more OK to run a single version forever if your only consumers are internal developers who will always be willing to pay your switching costs, but it is a bigger problem if your Web API is operating in a competitive marketplace where a breaking change could give a customer a reason to shop around.

  • Great post.

    It’s tough to disagree with your first point; usable API design is essential. I’d also add that it is important to keep in mind “one-size-fits-all” is a bad API strategy. Most customers will need to design multiple interfaces against the same internal components in order to meet the needs of a growing list of API consumers.

    On the second point, it is wise to remember that “versioning” is not a feature, just a technique. In tightly-coupled source code, detailed version numbers make sense and solve real problems. In public-facing Web interfaces, version numbers rarely add value and always increase brittleness. I’ve worked with at least one Web API library that spans more than seven years, supports three user products, and has added dozens of features all without ever breaking deployed clients and all w/o using version numbers in the public API.

    Finally, I agree 100% that dependence that external APIs pose a potential threat. The best way to protect yourself against the variances of interfaces you do not control is to put them at “arms-length.” All my designs actually place a full API facade or proxy between the API I publish and the APIs I consume.

    In my experience, great design, planning for evolvability, and employing facades to protect your system against uncontrollable external changes all help create a usable, stable, and evolvable product that will last a long time.