Tag Archives: APIs

New eBook: Five Simple Strategies For Securing Your APIs

Recently I wrote about the excitement I feel working within CA. This company is full of talented people, and when you draw on their capabilities, amazing stuff happens. Here in R&D we have some innovative solutions underway that are a tangible result of CA and Layer 7 working well together. I can’t reveal these yet, but you can see the same 1+1=3 equation at work in other groups throughout the organization.

Here is a good example. It’s an eBook we’ve assembled to help managers and developers build more secure APIs. The material started with a presentation I first delivered at a recent RSA show. We updated this with best practices developed by real customers facing real challenges. The content is solid, but what I love is the final product. It’s accessible, easy to digest, and the layout is fantastic. Half the battle is delivering the message so that it’s clear, approachable and actionable. This is just what we delivered. And best of all, it’s free.

The last year has been a difficult one in security. The Snowden affair made people talk about security; this, at least, is good and the dialog continues today. But if 2013 was a year of difficult revelation, 2014 is going to be about back-to-basics security.

APIs offer tremendous business value to enterprise computing. But they also represent a potential threat. You can manage this risk with a solid foundation and good basic practices, but you need to know where to start. This is the theme of our new eBook. It offers simple guidelines, not tied to a particular technology. You should apply these whenever you deploy APIs.

I hope you find this eBook useful. As always, I’d love to hear your feedback.

Download: Five Simple Strategies For Securing Your APIs.

Cisco and the Internet of Everything

John Chambers, CEO of Cisco, just published a good blog entry about the potential for change caused by universal connectivity, not just of our mobile gadgets, but of pretty much everything. Much has been made of late of the so-called “Internet of Things (IoT)”, to which Cisco is upping the scope and going so far as to make a bold estimate that 99.4% of objects still remain unconnected. This of course is great fodder for late night talk show hosts. I’ll leave this softball to them, and focus instead on some of the more interesting points in Chamber’s post and the accompanying white paper.

It strikes me that there might be more to Cisco’s Internet of Everything (#I0E) neologism than just a vendor’s attempt to brand what still may be a technology maverick. Internet of Everything sounds so much better than the common alternative when you append Economy on the end, and this is how it first appears in Chamber’s post. And that’s actually important, because adding economy in the same breath is an acknowledgement that this isn’t just marketing opportunism as much as a recognition that like mobility, the IoE is a potentially great catalyst for independent innovation. In fact, Cisco’s paper really isn’t about technology at all, but instead an analysis of market potential represented in each emerging sector, from smart factories to college education.

It is exactly this potential for innovation—a new economy—that is exciting. The combination of Mobile+APIs was so explosive precisely because it combined a technology with enormous creative potential (APIs) with a irresistible business impetus (access to information outside the enterprise network). The geeks love enabling tools, and APIs are nothing if not enabling; mobile just gives them something to build.

I0E of course is the ultimate business driver—and leveraging APIs as the enabler, it equals opportunity of staggering proportion. Like mobile before it—and indeed, social web integration before this—IoE will come about precisely because the foundation of APIs already exists.

It is here where I disagree with some IoT pundits who advocate specialized protocols to optimize performance. No thank you; it isn’t 1990 and opaque binary protocols no longer work for us except when streaming of large data sets (I’m looking at you, video).

Security in the IoE will be a huge issue, and on this topic Cisco has this to say:

IoE security will be addressed through network-powered technology: devices connecting to the network will take advantage of the inherent security that the network provides (rather than trying to ensure security at the device level).

I agree with this, because security coding is still just too hard and too easy to implement wrong. One of the key lessons of mobile development is that we need to make it easy for developers to enable secure communications automatically. Take security out of the hands of developers, put it in the hands of dedicated security professionals, and trust me, the developers will thank you.

As IoE extends to increasingly resource-constrained devices, the simpler we can make secure development, the better. Let application developers focus on creating great apps, and a new economy will follow.

The iPad Mini is for Cars

Yesterday, Apple launched the iPad mini. Apple events in the fall of 2012 may no longer command the social anticipation of only a few years ago, but they remain flash points for technology reporting. This release brought on more than its share of speculation that the mini is simply an overdue acknowledgement that Amazon got something right with Kindle, and that Apple has quietly slipped into following mode. Some pundits have seized on the angle that Apple’s new tablet appeared to contradict Job’s famous trashing of the 7″ form factor. But in all of the hullabaloo one observation seems to be missing. That is, a tablet of this size is tailor-made for inclusion into the dashboard of your car.

Nothing dates a car like its electronics. And nothing is more tragic that the UX of pretty much every single in-car navigation and music system. The luxury car segment can do Corinthian leather and wood grain appointments like no industry on earth. They can build a magnificent driving machine that powers through rain and snow like it was a sunny day in LA. But ask them to do a screen-based app and you get something that looks like it was designed on a TRS-80.

I didn’t renew the trial SiriusXM in my 4Runner because I couldn’t stand its programming compared with what I could stream from my iPhone using Bluetooth. Every time I rent a car I use my phone-based Navigon app over any provided GPS because my app is just better. I’m hooked on Waze despite how few people use it up here in Vancouver (you should sign up—the more people who use it, the better the traffic data is). The apps on my phone are always up-to-date and I replace the hardware every couple of years for the latest model (which is good enough for me; after all, it’s only a phone).

All cars need is a standard, lockable frame where you can plug in the device of your choice, plus a standardized connector. Then let free market competition and innovation prevail over Apps. Tomorrow’s gear heads aren’t going to be like the hot rodders of my Dad’s generation or the tuner kids of a decade ago. They are going to be geeks with Apps using APIs.

That’s what the iPad mini is for.

(It’s interesting to note that the wifi-only mini has no GPS, but the cellular version does…)

Hey Twitter: API Management = Developer Management

Quick question for you: What matters most, the client or the server?

Answer: Neither—they are really only useful as a whole. A client without a server is usually little more than an non-functional wire frame, and a server without a client is simply unrealized potential. Bring them together though, and you have something of lasting value. So neither matters more, and in fact each matters a lot less than half.

In the API world, this is an easy point to miss. The server-side always wields disproportionate power by virtue of controlling the API to its services, and this can easily foster an arrogance about the server’s place in the world. This effect is nicely illustrated by Twitter’s recent missteps around developer management.

The problems for Twitter all began with a blog entry. Blogs are the mouthpiece of the platform. Tucked away within an interesting entry about Twitter Cards and the potential to run applications within tweets (something which is genuinely exciting), can be found a restatement of an early warning to developers:

“developers should not ‘build client apps that mimic or reproduce the mainstream Twitter consumer client experience.’”

Ominous stuff indeed. This was quickly picked up on by Nick Bilton writing in the New York Times Bits blog, who pointed out that the real problem is that Twitter just isn’t very good at writing client-side apps that leverage it’s own API. Stifling competition by leveraging your the API power card can only alienate developers—and by extension the public who are left with a single vendor solution. Suddenly, it feels like the 1980s all over again.

This ignited a firestorm of concern that was well summarized by Adam Green in Programmable Web. Green acknowledges that API change is inevitable, but points out that this is something that can be managed effectively—which is not what Twitter is doing right now.

The irony of the whole thing is that in the past, by exercising its power position Twitter has actually made great contributions to the API community. In mid 2010, Twitter cut off basic authentication to APIs in favor of OAuth, a drop-dead event that became known as the OAuthcalypse. Hyperbole aside, in terms of actual impact on the populace this cut over made even Y2K look like the end of days. Given a tractable challenge, developers cope, which is really Green’s point.

What is important to realize is that API management isn’t technical but social. Win the community over and they will move mountains. Piss them off, and they will leave in droves for the next paying gig.

The thing I always remind people is that as a trend, APIs are not about technology; they are a strategy. Truth is, the technology is pretty easy—and that’s the real secret to API’s success. You see, the communications are never the thing; the app is the thing (and that is what WS-* missed). Simplicity and low barrier to entry counts for everything because it means you can get on with building real apps.

Now I can give you the very best infrastructure and tools to facilitate API community. But how you manage this community—well, that is where the real work begins, and in the end, it is all a lot less deterministic than we technologists like to admit. People are hard to manage, but communities are even harder.

If there is a lesson here, it is that APIs are really about potential, and that potential can be only realized when you have two sides—client and server—fully engaged. Mess this one up and you’re left with just a bunch of unused interfaces.

Platform Comes To Washington

Everyone wants his or her government to be better. We want more services, better services, and we want it delivered cheaper. Politicians come and go, policies change, new budgets are tabled, but in the end we are left with a haunting and largely unanswerable question: are things better or worse than they were before?

One thing that is encouraging and has the potential to trigger disruptive change to the delivery of government services in the US is the recent publication Digital Government: Building a 21st Century Platform to Better Serve the American People. The word to note here is platform; it seems that government has taken a page from Facebook, Twitter, and the others and embraced the idea that efficient information delivery is not about a carefully rendered Web page, but instead is really a logical consequence of developing an open platform.

I confess to some dread on my first encounter with this report. These publications are usually a disheartening product of weaselly management consultant speak refined through the cloudy lens of a professional bureaucrat (“we will be more agile”). But in this instance, the reverse was true: this report is accessible and surprisingly insightful. The authors understand that mobility+cloud+Web API+decentralized identity is an equation of highly interrelated parts that in summation is the catalyst for the new Internet renaissance. The work is not without its platitudes, but even these it bolsters with a pragmatic road map identifying actions, parties’ responsible, and (gasp) even deadlines. It’s actually better than most business plans I’ve read.

Consider this paragraph clarifying just what the report means when it calls for an information-centric approach to architecture:

An information-centric approach decouples information from its presentation. It means beginning with the data or content, describing that information clearly, and then exposing it to other computers in a machine-readable format—commonly known as providing web APIs. In describing the information, we need to ensure it has sound taxonomy (making it searchable) and adequate metadata (making it authoritative). Once the structure of the information is sound, various mechanisms can be built to present it to customers (e g websites, mobile applications, and internal tools) or raw data can be released directly to developers and entrepreneurs outside the organization. This approach to opening data and content means organizations can consume the same web APIs to conduct their day-to-day business and operations as they do to provide services to their customers.

See what I mean? It’s well done.

The overall goal is to outline an information delivery strategy that is fundamentally device agnostic. Its authors fully recognize the growing importance of mobility, and concede that mobility means much more than the mobile platforms—iOS and Android, among others—that have commandeered the word today. Tomorrow’s mobility will describe a significant shift in the interaction pattern between producers and consumers of information. Mobility is not a technological instance in time (and in particular, today).

But what really distinguishes this report from being just a well-researched paper echoing the zeitgeist of computing’s cool kids, is how prescriptive it is in declaring how government will achieve these goals. The demand that agencies adopt Web APIs is a move that echos Jeff Bezos’ directives a decade ago within eBay (as relayed in Steve Yegge’s now infamous rant):

1) All teams will henceforth expose their data and functionality through service interfaces.

It was visionary advice then and it is even more valid now. It recognizes that the commercial successes attributed to the Web API approach suggest that just maybe we have finally hit upon a truth in how system integration should occur.

Of course, memos are easy to ignore—unless they demand concrete actions within a limited time. Here, the time frames are aggressive (and that’s a good thing). Within 6 months, the Office of Management and Budget (OMB) must “Issue government-wide open data, content, and web API policy and identify standards and best practices for improved interoperability.” Within 12 months, each government agency must “Ensure all new IT systems follow the open data, content, and web API policy and operationalize agency gov/developer pages” as well as “optimize at least two existing priority customer-facing services for mobile use and publish a plan for improving additional existing services.”

If the recent allegations regarding the origins of the Stuxnet worm are accurate, then the President clearly understands the strategic potential of the modern Internet. I would say this report is a sign his administration also clearly understands the transformational potential of APIs and mobility, when applied to government.

APIs, Cloud and Identity Tour 2012: Three Cities, Two Talks, Two Panels and a Catalyst

On May 15-16 2012, I will be at the Privacy Identity Innovation (pii2012) conference held at the Bell Harbour International Conference Center in Seattle. I will be participating on a panel moderated by Eve Maler from Forrester, titled Privacy, Zero Trust and the API Economy. It will take place at 2:55pm on Tuesday, May 15th:

The Facebook Connect model is real, it’s powerful, and now it’s everywhere. Large volumes of accurate information about individuals can now flow easily through user-authorized API calls. Zero Trust requires initial perfect distrust between disparate networked systems, but are we encouraging users to add back too much trust, too readily? What are the ways this new model can be used for “good” and “evil”, and how can we mitigate the risks?

On Thursday May 17 at 9am Pacific Time, I will be delivering a webinar on API identity technologies, once again with Eve Maler from Forrester. We are going to talk about the idea of zero trust with APIs, an important stance to adopt as we approach what Eve often calls the coming identity singularity–that is, the time when identity technologies and standards will finally line up with real and immediate need in the industry. Here is the abstract for this webinar:

Identity, Access & Privacy in the New Hybrid Enterprise

Making sense of OAuth, OpenID Connect and UMA

In the new hybrid enterprise, organizations need to manage business functions that flow across their domain boundaries in all directions: partners accessing internal applications; employees using mobile devices; internal developers mashing up Cloud services; internal business owners working with third-party app developers. Integration increasingly happens via APIs and native apps, not browsers. Zero Trust is the new starting point for security and access control and it demands Internet scale and technical simplicity – requirements the go-to Web services solutions of the past decade, like SAML and WS-Trust, struggle to solve. This webinar from Layer 7 Technologies, featuring special guest Eve Maler of Forrester Research, Inc., will:

  • Discuss emerging trends for access control inside the enterprise
  • Provide a blueprint for understanding adoption considerations
You Will Learn

  • Why access control is evolving to support mobile, Cloud and API-based interactions
  • How the new standards (OAuth, OpenID Connect and UMA) compare to technologies like SAML
  • How to implement OAuth and OpenID Connect, based on case study examples
  • Futures around UMA and enterprise-scale API access

You can sign up for this talk at the Layer 7 Technologies web site.

Next week I’m off to Dublin to participate in the TMForum Management World 2012. I wrote earlier about the defense catalyst Layer 7 is participating in that explores the problem of how to manage clouds in the face of developing physical threats. If you are at the show, you must drop by the Forumville section on the show floor and have a look. The project results are very encouraging.

I’m also doing both a presentation and participating on a panel. The presentation title is API Management: What Defense and Service Providers Need to Know. Here is the abstract:

APIs promise to revolutionize the integration of mobile devices, on-premise computing and the cloud. They are the secret sauce that allows developers to bring any systems together quickly and efficiently. Within a few years, every service provider will need a dedicated API group responsible for management, promotion, and even monetization of this important new channel to market. And in the defense arena, where agile integration is an absolute necessity, APIs cannot be overlooked.

In this talk, you will learn:

·      Why APIs are revolutionizing Internet communications
– And making it more secure
·      Why this is an important opportunity for you
·      How you can successfully manage an API program
·      Why developer outreach matters
·      What tools and technologies you must put in place

This talk takes place at the Dublin Conference Centre on Wed May 23 at 11:30am GMT.

Finally, I’m also on a panel organized by my friend Nava Levy from Cvidya. This panel is titled Cloud adoption – resolving the trust vs. uptake paradox: Understanding and addressing customers’ security and data portability concerns to drive uptake.

Here is the panel abstract:

As cloud services continue to grow 5 times faster vs. traditional IT, it seems that also concerns re security and data portability are on the rise. In this session we will explain the roots of this paradox and the opportunities that arise by resolving these trust issues. By examining the different approaches other cloud providers utilize to address these issues, we will see how service providers, by properly understanding and addressing these concerns, can use trust concerns as a competitive advantage against many cloud providers who don’t have the carrier grade trust as one of their core competencies.  We will see that by addressing fraud, security, data portability and governances risks heads on, not only the uptake of cloud services will rise to include mainstream customers and conservative verticals, but also the type of data and processes that will migrate to the cloud will become more critical to the customers

The panel is on Thursday, May 24 at 9:50am GMT.

The Well-Designed API

We have worked with many APIs here at Layer 7. And over time we’ve seen it all, ranging from the good to the bad. We even see the downright ugly. Now a good API is a beautiful thing; it encourages innovation, abstracts appropriately, and is designed with enough forethought that nobody needs to change it down the road. Resiliency is a good quality in an API. APIs are a little like cockroaches in that they will likely outlive the human race.

But what about the other ones? The ugly and bad ones? This is where developers could use some guidance.

Truth is, good API design isn’t really hard, but it’s not easy. One thing I point people to is Leonard Richardson’s Maturity Model for REST, which Martin Fowler explores in his blog. Now I’m not a REST purist by any means—truth is I’m as guilty of quick-and-dirty HTTP tunneling hacks as the next guy—but when you see the maturity phases laid out so succinctly, you can’t help but be inspired to move toward more “resourceful” thinking and maybe even learn to love HATEOS. Part of good API design is knowing what you should aspire to, and Richardson’s model is much more concise and accessible than Fielding’s thesis.

Another good source of advice is Joshua Bloch’s superb Google Tech Talk How to Design A Good API and Why it Matters. Bloch wrote what is arguably the most important book about Java ever written, and indeed his talk is about APIs using Java as the model. But don’t let that deter you; virtually everything Bloch discusses is as relevant to RESTful JSON-style APIs as it is to Java. Follow his advice, transpose it to you language of choice, and frame it with an understanding of where you want to land in the maturity model for REST, and you will end the day with great APIs.

Developers, Developers, Developers – Why API Management Should be Important To You Featuring RedMonk

It’s about developers again.

Everything in technology goes through cycles. If you stick around long enough, you begin to see patterns emerge with an almost predictable regularity. I actually find this comforting; it suggests we’re on a path of refinement of fundamental truths that date back in a continuous line though Alan Kay to Turing and beyond.

The wrong way to react to technology cycles is with the defensive-and-crusty “this is nothing new kid—we did it back in ’99 when you were stuck in the womb.” Thanks for nothing, Grandpa. A better approach is to recognize the importance of new energy and momentum to make great things happen.

The cycle that really excites me now is the new rise of the developer. Trying my best not to be crusty, there is a palatable excitement and energy out there that really does feel like it did in 1999. After years of outsourcing, after years of commoditization, developers matter again. A lot. It’s like the world has rediscovered the critical importance of this fundamentally creative endeavor.

This is a golden age of technology and possibility, one that is being driven by new blood and newer technology. The catalyst is the achingly perfect collision of cloud, mobility and social discovery with APIs, node.js, Git, NoSQL, HTML5, massive scalability… (I really could go on and on here).

Most of all, I’m excited by movements like Codecademy. This simple idea perfectly reflects the tenor of the time in which we live. People are no longer afraid of making things easy. The priesthood is gone; coding is now confident and mature.

I’ll be talking more about these topics and the important role APIs play in an upcoming webinar I will be delivering with James Governor, co-founder of Redmonk. This is the analyst firm that truly is at the heart of the new developer movement. I hope you can join us Thursday, April 19 at 9am Pacific. This one is going to be good.

QCon London 2012 Is The Place To Be This Week

I’m off to London for QCon 2012, the 6th International Software Development Conference. I am one of the track chairs for this meeting. I’ve just learned that the show is now sold out, but there is a wait list if you have not already registered. All indications are that this is going to be an outstanding conference, so if there is any way you can possibly attend, you should make the effort.

I’m hosting a track this Friday called Industrial-Strength Architecture for Integration and Web Computing. Here is how I described the track to potential speakers:

The enterprise is demanding more from the Web than ever before. No longer content with simple web application delivery, the new enterprise web has become an integration point between mobile devices, browsers, legacy systems, and third-party web apps. It is a difficult balancing act. The new enterprise web is highly scalable, but can also reconcile the different service level expectations across each participant. At its core, it enables agile product delivery while maintaining extreme reliability. In this track, we will study the architectural challenges faced by the enterprise that needs to harness the web as a rich delivery channel—and highlight the real world solutions that address these.  We will explore the intersection where trends such as virtualization, noSQL, JSON, OAuth, APIs and mobile apps meet. Join us to understand the fine tuning between milliseconds and dollars that can make the difference between wild success and disappointing mediocrity.

I’m fortunate to have a great roster of speakers, including Theo Schlossnagle from Omniti, Paul Fremantle from WSO2, John Davies from Incept5, and finally both Marcus Kern and David Dawson from Mobile Interactive Group.

I’m also going to chair a panel titled Integration At Scale: Lessons Learned From The New Enterprise Web. This one promises to be a very interesting discussion:

The mobile device revolution has upended our traditional view of the world wide web. The enterprise web is now about integration: connecting any device to to any data, reliably and under wildly fluctuating load. How has this affected web architecture, and what changes in the day-to-day operation of the web resource? Join us for this panel of senior enterprise architects, each of whom has met the challenge of the new enterprise web.

The panel line up consists of David Laing from CityIndex, Neels Burger from MoneySuperMarket.com, Neil Pellinacci form Tanzarine Technology, and Parand Tony Darugar from Xpenser. Each brings tremendous experience to the panel, and bringing them all together is going to make for a lively and informative debate. I’m looking forward to it.

Hope to see you in London.

Gartner AADI 2011 Presentation Video: API Management, Governance & OAuth

I delivered a talk all about API governance at last week’s Gartner Application Architecture, Development and Integration (AADI) summit in Las Vegas. I was the lunch time entertainment on Wednesday. The session was packed—in fact, a large number of people were turned away because we ran out of place settings. Fortunately, a video of the session is now available, so if you were not able to attend, you can now watch it online.

In this talk I explore how governance is changing in the API world. I even do a live OAuth demonstration using people, instead of computers. Unlike the classic “swim lane” diagrams that only show how OAuth works, this one also teaches you why the protocol operates as it does. (If you want to skip directly to the OAuth component, it begins at around 22 minutes. )