While applications, users, and data continue to float into the Cloud, there’s a boisterous argument underway back on the ground among the architects, designers, and software developers who make all of this magic possible. At its core, the debate centers on the proper technique to use when communicating with services that reside in the Cloud. On one side of the fence are adherents of SOAP-based services. They’re facing off against fans of the Representational State Transfer (REST) style of interoperability. In many ways, though, this is a false dichotomy: the same core service logic can be exposed for concurrent access via many different protocols, including SOAP, REST, JMS, plain XML, and JDBC to name just a few. However, if you’re creating a technology platform for the mass market, you’ll need to select one as your native protocol.
Way back in 2006 we decided that the relatively new REST approach offered distinct advantages over SOAP. Before I tell you why, it’s important to remember that while SnapLogic is built on REST, it’s perfectly capable of interacting with SOAP services (and many other protocols as well).
SOAP is all about servers talking to servers, with rigid standards, extensive design, serious programming, and heavyweight infrastructure all essential parts of the equation. If you’re building a mission-critical distributed application that will spend its life behind your corporate firewall and be serviced by a squadron of highly trained developers who know your environment inside and out, SOAP is a great choice.
Made for the Cloud
On the other hand, if you’re interested in building your applications quickly and with maximum portability, especially if the Cloud (public, private, or hybrid) is in the picture, it’s hard to beat REST. It sports a mere handful of simple HTTP API commands, and every object (known as a resource) has its own unique Uniform Resource Identifier (URI) that provides a path and distinct name. This should be very familiar to you: every time you access a specific Web page, you tell your browser where the page is hosted along with its name.
Developer-Friendly, Secure & Scalable
This straightforward API and clear, consistent labeling philosophy is far more developer-friendly than SOAP, which mandates deep understanding of site-specific APIs. REST lets you publish your data and have others, regardless of where they might be, work with it. Just looking at the URI gives you an indication of how to proceed. Yet despite all of these advantages, basing SnapLogic on REST gave us the same security and massive scalability as the overall Web itself.
Critics of REST might argue that generalizing the component interface limits the capabilities of the system. These critics fail to see the great power in the simplicity of a uniform interface, especially at larger scales.
Aaron Skonnard explains this beautifully using a LEGO® metaphor. If you’ve played with LEGO® products before, you know there are only a few ways to connect them together, which represents the LEGO® uniform interface. All LEGO® products, regardless of when or where you buy them, can connect with one another through its uniform interface. When new LEGO® products are released, they can be incorporated into existing LEGO® systems and the user doesn’t have to learn anything new. The new components work just like all other LEGO® products. You might wonder if the limited number of connection possibilities will constrain what you’re able to build with LEGO® products. But if you’ve ever been to LEGOLAND®, you’ll know it doesn’t. You’ll find some incredibly complex objects at LEGOLAND®, including replicas of cars, buildings, even dinosaurs, which were all built from a variety of LEGO® products, connected through the LEGO® uniform interface.
For those of you that read my previous post on the Science Behind Snaps, these concepts should start to sound familiar to you, Snaps have a uniform interface, interoperate with each other because they follow the same pattern, use the same API, and leverage the same underlying infrastructure supplied by the SnapLogic integration platform.
Our Bet Has Paid Off
I’m happy to report that the bet we made in 2006 has paid off. The market has spoken: RESTful services are much more popular than SOAP-based services, particularly in organizations that have grown up using the Internet. It’s a self-reinforcing loop: since REST allows you to easily integrate hundreds of data source that are already available on the Web, and more arrive each day. To work with them, you only need to know one protocol, a basic naming convention, and a few simple API commands.
How about you? What experiences have you had with REST or SOAP?