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, Salesforce.com, 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 or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.