My work colleague turned around to me and said, “Web Services aren’t APIs”. That didn’t sound right so I started investigating. What is the difference and why is it important?

Applications have been built and constructed from re-usable and shared components since the bloody epoch. It’s why software is eating everything. Once a standard interface – and usually a corresponding library – is agreed upon there’s little reason to go back to first principles again. It’s division of labour, driven by pure need, evolving organically.

Then along came ubiquitous, always-available connectivity and expanding bandwidth. Why bother compiling and distributing an API/Library when the same API call could be made to a shared network service? A web service.

So a web service is a type of API. Not all APIs are web services though. APIs are the public interface for a piece of code – it is what you can call from within your code. It may be a web service, but it could also be a Java library or similar.

Wikipedia has a web services as “… a software function provided at a network address over the web”. That’s a pretty good definition. It must also be loosely coupled, which means that both the service caller and owner agree on the interface but know little about each other. The back end class can be substituted as needed.

Companies are themselves creating their own web service APIs. Here’s an API for business listings at Australia’s Yellow Pages and here’s one I’m looking at now to do some useful work on my expanding Evernote database. Both of these are web services with some extra API management capabilities. Grab yourself key and start developing!

Amazon was miles ahead of the curve on this. This famous post by Steve Yegge describes the famous Jeff Bezos mandate (in 2002!) that all teams at Amazon must:

  1. Expose their data and functionality through data services,
  2. Teams must communicate only through these interfaces (no direct database links etc.),
  3. All interfaces must be designed to be accessed externally

and a few other things. Talk about ahead of the curve.

It’s the future mesh of interconnectivity. One big “programmatical” mash-up.

There are the web services you own and the ones you don’t. With regards to the ones you do own, you’ll have to think about how you maintain some control of the integration. Two possible models are shown below. Do you have an integration bus/relay/proxy in each cloud so as to minimise network traversals, or do you have a few centralised integration points to make control and standards (and non-functional requirements like logging, access control, templates etc.) easier.

Web service cloud options

For the web services you don’t own but use, how much do you rely on single vendors, how do you manage keys and how do you manage different standards/skill sets etc.

I’ve always thought of “The Cloud” as a technology theme that is behind many new implementations, but I’m starting to think “the Cloud” is just a biblical plague of web services. It’s even hidden the in term “as-a-service”! All SaaS, PaaS and IaaS providers have public web service APIs built in from day one.