Welcome!

Between Cloud, Mobility and the Enterprise is the API Middle Ground

Scott Morrison

Subscribe to Scott Morrison: eMailAlertsEmail Alerts
Get Scott Morrison via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Blog Feed Post

REST is Simple, But Simple is not REST

Last December, William Vambenepe posted a provocative blog entry about RESTful APIs in the cloud. In it, he states that Amazon proves that REST doesn’t matter for Cloud APIs. Writing over at InfoQ, Mark Little re-ignited the controversy in his recent post asking Is REST important for Cloud? And Vambenepe responded to the re-invigorated commentary in Cloud APIs are like Military Parades. All of these posts are very much worth reviewing, and be sure to read the comments left by members of the community.

Amazon’s query APIs are certainly not textbook examples of the RESTful architectural style, a point the Restafarians are quick to make. But they are simple, understandable, and very easy to implement, which is largely the set of characteristics that attracted developers to REST in the first place. REST does have a satisfying elegance and undeniable philosophical appeal, but accessibility probably counts for more in the popularity stakes. If there is one theme that repeats throughout the history of computing, surely it is the story of simple and good enough winning the day.

Amazon’s APIs are not the reason that AWS is such a resounding success; it is the service offering that was responsible for that. However, the APIs were good enough that they didn’t hinder Amazon’s success, and this is the relevant point. Dig a little deeper, though, and Amazon’s API story offers some interesting insights.

Amazon, it turns out, is a good case study illustrating the evolution of Internet APIs. When AWS first appeared, Amazon engineers faced what at the time was an unresolved question of style: should a cloud publish SOAP services, or RESTful APIs? I’ve heard that question led to some pretty heated internal debates, and I don’t doubt this is true. Amazon lies in Microsoft’s backyard, and .NET in those days was very firmly in the SOAP camp. REST, however, was rapidly gaining mind share, especially due to the growing popularity of AJAX in Web 2.0 apps.

The engineer’s solution was to hedge, producing a mix of SOAP, a “REST-like” query (HTTP with query params as NVPs), and REST APIs somewhat in parallel. Developers gravitated toward the later two options so much more than SOAP that AWS left the orbit of WS-* for good. Amazon gave the market choice, and the market spoke decisively. This was an interesting experiment, and in performing it Amazon actually led the way—as they have in so many ways—for future cloud providers. Each new provider had the luxury of an answer to the question of API style: REST won (even if this wasn’t really REST). Now all an emerging cloud provider needed to do was to design their API according to current best practices, and this is something for which experience counts. Roy Fielding’s thesis may have come out in 2000, but the appreciation of what constitutes good RESTful design among developers is a much more recent phenomena, one that has benefited greatly from the growing popularity of this style.

APIs are of course simply an interface between components of a distributed application. Like any interface, properly versioned, they can evolve. One thing I’ve noticed lately is that our customers are increasingly using Layer 7 technology to refine their APIs as they come to better understand their own needs.

For example, we have a customer in the publishing industry that is actually adapting existing SOAP-based APIs to RESTful design principles. They use our SecureSpan Gateways to present a true REST facade, and adapt this to existing SOAP messages on-the-fly. This transformation is fairly mechanical; what is more important is that the exercise also gave their developers the opportunity to refine their API suite to better meet their needs. Many of their new RESTful APIs leverage SecureSpan’s orchestration capabilities to consolidate multiple SOAP calls behind a single REST call. The resulting API 2.0 is a better match to their current business—and best of all, they were able to do all of this without writing a line of new code.

The lesson here is that while we like to think that APIs are perfectly static and never change, the truth is that we rarely get interfaces right the first time. Requirements change, business moves, and our understanding advances. What is important is that your APIs can respond with agility to changing needs, because change, we all know, is inevitable.


Read the original blog entry...

More Stories By Scott Morrison

K. Scott Morrison is the Chief Technology Officer and Chief Architect at Layer 7 Technologies, where he is leading a team developing the next generation of security infrastructure for cloud computing and SOA. An architect and developer of highly scalable, enterprise systems for over 20 years, Scott has extensive experience across industry sectors as diverse as health, travel and transportation, and financial services. He has been a Director of Architecture and Technology at Infowave Software, a leading maker of wireless security and acceleration software for mobile devices, and was a senior architect at IBM. Before shifting to the private sector, Scott was with the world-renowned medical research program of the University of British Columbia, studying neurodegenerative disorders using medical imaging technology.

Scott is a dynamic, entertaining and highly sought-after speaker. His quotes appear regularly in the media, from the New York Times, to the Huffington Post and the Register. Scott has published over 50 book chapters, magazine articles, and papers in medical, physics, and engineering journals. His work has been acknowledged in the New England Journal of Medicine, and he has published in journals as diverse as the IEEE Transactions on Nuclear Science, the Journal of Cerebral Blood Flow, and Neurology. He is the co-author of the graduate text Cloud Computing, Principles, Systems and Applications published by Springer, and is on the editorial board of Springer’s new Journal of Cloud Computing Advances, Systems and Applications (JoCCASA). He co-authored both Java Web Services Unleashed and Professional JMS. Scott is an editor of the WS-I Basic Security Profile (BSP), and is co-author of the original WS-Federation specification. He is a recent co-author of the Cloud Security Alliance’s Security Guidance for Critical Areas of Focus in Cloud Computing, and an author of that organization’s Top Threats to Cloud Computing research. Scott was recently a featured speaker for the Privacy Commission of Canada’s public consultation into the privacy implications of cloud computing. He has even lent his expertise to the film and television industry, consulting on a number of features including the X-Files. Scott’s current interests are in cloud computing, Web services security, enterprise architecture and secure mobile computing—and of course, his wife and two great kids.

Layer 7 Technologies: http://www.layer7tech.com
Scott's linkedIn profile.
Twitter: @KScottMorrison
Syscon blog: http://scottmorrison.sys-con.com