API Trends: What to expect in 2012 »

Thanks to all who participated in last week's webinar:  "API Trends: What to expect in 2012" with Sam @sramji, Anant @jhingran, and Brian @brianpagno.

Here are the video and slides. Thanks for a great interactive session.

We'd love to hear more of your thoughts and questions; please join the conversation on the api-craft forum.

Video and Slides - “Developer segmentation for your API”  strategy webinar »

Thanks to all that attended last week's API strategy webinar "Developer Segmentation for your API" on developer community and market size. (And thanks to our speakers @sramji  and @landlessness).

Here are the video and slides (and as always, you are free to use under Creative Commons).

Is enterprise cloud adoption going through a lull ? »

I recently broke my collarbone and couldn't type.   So spent a lot of time catching up with some smart folks like Christopher Hoff.  Interesting that many of us thought it seems like we are going through a lull in enterprise buying of cloud technologies.

I do see what they are saying -  it seems like many of the CIO's who were gung ho to do summer pilot projects are slowing down...why?

I do not think this is a lull - instead the splashing water (survivcal mentality) is starting to go away..    The economy is getting better (or this is anticipated - almost the same thing).  Now the pressure's on to act quickly on trying out new things either to increase revenue or save $$'s.

Executives are getting back into a regular budget cycle, and this is planning time for most companies as they get back to thinking how to show good results and pitch budget needs for next year.

We at Sonoa are convinced that promise of cloud is strong as ever and our customers pilots are going into production w/ awesome results. The wave will continue to build into next year as more success stories are discussed - get ready!

What is an API and how is it different than a Web service? »

Over two years with Sonoa, I’ve talked to customers about APIs for hours every day and see a lot of common patterns. I thought I’d start this blog out by talking a little bit about what we've seen. More companies of all sizes are building web services APIs so that they can make their own capabilities available to a wider audience. The concept of an “API” on the Internet is not new but it’s been taking off, especially recently. At this point, if your company isn’t offering such API, it probably will be before long.

What’s an API? In computer science we’ve used the term “Application Programming Interface,” or “API,” for pretty much forever. Everything from the Windows operating system to the Oracle database has an API. What I’m talking about is a little more specific — a “web services API”. That means some functionality that you can invoke over the Internet. Specifically, an “API” in this context:

• Is invoked over the public Internet
• Almost always uses HTTP (or HTTPS) as its communications protocol
• Often uses XML to represent a response
• Often uses either HTTP query parameters or some XML to represent a request

For these reasons, a good API often requires no special client-side software. The most successful APIs, like the Twitter API, can be used from anywhere on the Internet from literally any programming environment that can communicate using HTTP. The most effective and popular APIs are also simple.

For instance, in order to see the current status of Lance Armstrong on Twitter as an XML document, all I have to do is perform an HTTP GET to this Twitter API URL. And there are tons of examples like this - sites like ProgrammableWeb provide a great directory and stats of many APIs.

Aren’t API’s just web services? Well, yes they are. In fact, all web services match the description I put in the section above except for one thing — a web service does not necessarily have to be accessed using the public Internet. In fact, an awful lot of web services today run inside a corporate network and are never touched by the Internet.

But on the Internet the term “API” has become a lot more prevalent than the term “web service.” that is partly due to semantics — “web service” typically implies “SOA,” which to many people implies “SOAP,” which in turn makes people think, “big, complicated, and expensive.” (And if you don’t know what I was talking about in this paragraph then you probably had the same reaction.)

So from a purely pedantic perspective, an “API” is just a “web service.” But that doesn’t mean there isn’t an important distinction — typically, something called an “API” is designed for the Internet, to be consumed by many different types of clients, and if it is successful it is pretty simple. On the other hand, a SOAP web service running on a big “web services stack” inside a corporate network could be a thing of beauty that is widely adopted, or it could be a tangle of spaghetti that keeps one or two applications intimately intertwined for the foreseeable future.

Why build an API? One short answer is that an API is a great way to get more people to use the services that you offer. For instance, most Twitter traffic comes from its API, not from the web site. (If you’re using a desktop Twitter client like Twhirl or Spaz or even some of the iPhone or Blackberry apps, you’re using the Twitter API.) It also lets you focus on the functionality that your company provides rather than on presentation. Do you run a trucking company with great scheduling and routing capabilities? You can expose those as an API that your clients can embed into their own applications more easily than you can build a slick web site and keep it up to date with the latest fashions in web site design and implementation.

Next time I'll talk about some common challenges we see for folks building APIs. - Greg