Mike Amundsen

Mike Amundsen

Mike Amundsen is Layer 7’s Principal API Architect. An internationally-known author and lecturer, Mike travels throughout the United States and Europe, consulting and speaking on a wide range of topics including distributed network architecture, Web application development and cloud computing. His recent work focuses on the role hypermedia plays in creating and maintaining applications that can successfully evolve over time. He has more than a dozen books to his credit, the most recent of which is Building Hypermedia APIs with HTML5 & Node. He is currently working on a new book on “cloud stack” programming. When he is not working, Mike enjoys spending time with his family in Kentucky.

November 23rd, 2012

Our First API Academy Videos

API Academy Videos

I’m happy to announce the release of the first API Academy video shorts. I’ve been working with my colleague Ronnie Mitra to create a series of short (five-minute), informative videos on topics related to the Web, APIs and solution design/implementation.

These first few videos are just the start. We plan on doing more of these shorts on a wide range of topics, over the coming weeks and months. And we need your help. Please take a look at these first vids and send us your feedback.

You can comment here, on YouTube or by emailing me directly. We’re looking for feedback on the format, suggested topics and even how we could improve upon this model (hosting a separate site, adding interaction, badges etc.)

Any time you can spend on watching these and sending comments will be most appreciated. Our aim is to do something helpful, engaging and – above all – enjoyable. Thanks for your help and let’s see what this can become!

The API Interaction Model – An Introduction

Three Common Web Architecture Styles

Handle Errors on the Web

September 12th, 2012

RESTful or Not?

As the leader of Layer 7’s North American API Architecture & Design Practice, I often get asked to review Web solutions. Rarely do people ask me if the implementation is appropriate for the intended use. Instead they want to know if the work fits a label invented over a decade ago by a PhD candidate in his dissertation. They want to know if what they’ve come up with is “RESTful”.

Essentially, REST (representational state transfer) is a style. Specifically, it’s a style of network-based software architecture. This style was first defined in 2000 by Roy Fielding. Fielding stated that “an architectural style is a coordinated set of architectural constraints that has been given a name for ease of reference”.

The set of architectural constraints Fielding defined in his dissertation remain the key criteria by which we judge whether or not a service is RESTful. Back in 2000, Fielding did a very good job of defining the six primary constraints: client-server; stateless; cache; uniform interface; layered system; code-on-demand.

However, REST is also defined by four “interface constraints” that are only partially defined in the dissertation: identification of resources; manipulation of resources through representations; self-descriptive messages; hypermedia as the engine of application state. In particular, the definitions of self-descriptive messages and hypermedia are still debated.

Assuming you can decide on clear definitions of all 10 constraints, all that remains is to identify each of them within the target design. If the implementation does not exhibit all ten (well nine, since code-on-demand is optional), then it is not RESTful. This last step is not difficult. It is the previous step (agreeing on definitions) that causes problems.

Still not sure if your service is RESTful? Well, I originally published this post, in expanded form, on my personal blog. If you want to dig deeper, take a look over there.

September 6th, 2012

REST Fest 2012 in Greenville, SC

REST Fest 2012Over the weekend of September 13-15, a small band of Web architects and developers will – for the third year in a row – descend upon the town of Greenville, SC. They’ll be getting together to catch up on the events of the past year, share stories about recent projects and contemplate the future of Web and mobile applications.

This may sound like a typical tech conference but REST Fest is hardly that. Taking its cue from OpenSpaces and similar events, REST Fest is organized by attendees, for attendees. For example, one of the days is devoted to everyone hacking on the same general topic. Another is dedicated to short workshops, all presented by selected registrants.

Similarly, all the general session talks are delivered by the attendees themselves. That’s because one of the “rules” of REST Fest is “everyone talks and everyone listens”. When you sign up to join REST Fest, you are expected to deliver at least a five-minute lightning talk – and there are no exceptions!

Notable presenters will include keynote speaker Stu Charlton (former CTO of Elastra), Matt Bishop (Senior Product Architect at Elastic Path), Pat Cappelaere (currently working on NASA’s SensorWeb project), Leonard Richardson (co-author of O’Reilly’s RESTful Web Services), Sam Ramji (Head of Strategy at Apigee) and yours truly.

I feel privileged to be co-chair of REST Fest and I’m pleased to note that Layer 7 is the event’s Head Sponsor this year. Hope to see you there!

August 29th, 2012

Using WebSockets – Part 2: A Real-Time Challenge

HTTP vs WebSocketIn the previous blog post in this series (Using WebSockets – Part 1: Minding the Gates), Ronnie Mitra talked about the promise of the WebSocket protocol, as well as some security aspects. In this post, I’ll talk about some of the details of the protocol and what they mean for those planning their own WS implementations.

The first thing to keep in mind is that WebSocket is a high-level protocol with its own registered schemes (WS: and WSS:). The specification describes it as: “… intended to be as close to just exposing raw TCP to script as possible.” This is very different from HTTP, which is “…  an application-level protocol for distributed, collaborative, hypermedia information systems.”

That’s good and bad news. It means you have almost the full range of TCP at your disposal. It also means you have none of the established constraints and conventions of the more detailed and focused HTTP specification. This has implications for both design and implementation of WS solutions.

Originally designed with Web browsers in mind, the WS protocol can also be implemented for mobile, desktop, and other stand-alone clients. There are quite a few checks and balances in the specification in order to make it easy (and safe) for browsers to switch from HTTP to WS conversations, all from JavaScript.

However, since many installed browsers do not yet natively support the WS protocol, these checks and balances are not always employed. Instead, WebSockets implementations often take advantage of browser workarounds and fallbacks, in order to support the real-time communications the WS protocol was designed to provide.

It’s also important to remember the specification states: “While this protocol is intended to be used by scripts in web pages, it can also be used directly by hosts [which] can therefore send fake ‘Origin’ header fields, misleading the server.” Implementations that will receive requests from non-browser clients should include additional checks to ensure these requests are valid.

Finally, as the protocol was designed to support real-time communications, it won’t scale in the same way HTTP does. Since the server will keep connections open to all active clients in order to track and broadcast content, servers will need to maintain (or persist) information about each connected client (including knowing when that client is no longer connected!)

If your current HTTP implementations rely on server-based session state, you may not see much difference in the scaling limits of WS. Remember though, the Web’s scaling success is largely based on HTTP’s ability to handle client requests without requiring server-persisted data. Also, some software and implementation patterns designed for HTTP will not work for WS.

Implementing WS is not for the faint-of-heart: it’s not yet widely supported on installed browsers; it uses a different implementation model; it takes more effort/resources to scale it up as services become popular. However, there are some good libraries for coding WS solutions and it can be relatively easy to get started on implementing WebSockets.

But be ready. If you experience great success, you’re likely to have a challenge on your hands!

August 3rd, 2012

Standards, APIs & WAC

Wholesale Applications Community LogoGigaOM recently ran a piece opining the demise of the Wholesale Applications Community (WAC) after only a couple of years on the scene. The article complained that something like the WAC effort is needed and suggested that, given the nature of the industry and the players involved, it’s not likely to happen. However, what the author failed to notice was that the WAC’s attempted solution was way off the mark.

The WAC’s key failure was that it attempted to standardize the wrong thing: the API. This is a common problem that occurs repeatedly. GigaOm readers may recall another example of industry-level standards going astray, summarized in the “Cloudstack-Openstack Dustup” piece from April. I suspect several readers can call to mind similar cases in the not-too-distant past. Such cases usually share a common theme: disagreement on the details of the API.

The solution is right at hand but few see it. The right way to go is to standardize the way messages are designed and shared, not the data points and actions themselves. In other words, the key to successful shared standardization is through media-types and protocols. This is especially true for any communication over HTTP but it holds true for standards operating over any application-level protocol.

We don’t need to look too far to see an example of an industry-led standardization success. VoiceXML was started by AT&T, IBM, Lucent and Motorola as a way to standardize interactive voice system communications. Not long after the first markup was defined in 1999 (a process which took a matter of a few months), the standard was turned over to the W3C for continued growth and refinement.

The goals of VoiceXML were strikingly similar to those of the WAC and Cloudstack/Openstack efforts: defining an interoperable standard that could be used across an industry group. The difference in the case of VoiceXML was that the committee focused on message design and domain-specific details shared by all players. It did not attempt to document all the data elements, function calls and workflows to be used in lockstep by all.

Most likely, the WAC meltdown won’t be the last one we’ll see. But this is not the inevitable result of competing interests in the global marketplace. This is a result of well-meaning people aiming at the wrong target. We can do better. We can learn from successful interface designs and focus on making it possible to consistently communicate a wide range of information freely instead of attempting to constrain systems to a single set of possible interactions.

The future of an effective Web, a growing and vibrant distributed network, rests in the hands of those who would take on the task of writing the vital standards that will make it work. I look forward to seeing more efforts where the focus is on improving communication between parties through well-designed message formats instead of on limiting communication though constrained APIs.