ZapFlash

How I Became a REST “Convert”

Many of you know me as one half of the ZapThink team – an advisor, analyst, sometimes-trainer, and pundit that has been focused on XML, Web Services, SOA, and now Cloud Computing over the past decade or so. Some you may also know that immediately prior to starting ZapThink I was one of the original members of the UDDI Advisory Group back in 2000 when I was with ChannelWave, and I also sat on a number of standards bodies including RosettaNet, ebXML, and CPExchange initiatives. Furthermore, as part of the ZapThink team, I tracked the various WS-* standards from their inception to their current “mature” standing. I’ve closely followed the ups and downs of the Web Service Interoperability (WS-I) organization and more than a few efforts to standardize such things as business process. Why do I mention all this? To let you know that I’m no slouch when it comes to understanding the full scope and depth of the Web Services family of standards. And yet, when push came to shove and I was tasked with implementing SOA as a developer, what did I choose? REST.

Representational State Transfer, commonly known as REST, is a style of distributed software architecture that offers an alternative to the commonly accepted XML-based Web Services as a means for system-to-system interaction. ZapThink has written numerous times about REST and its relationship to SOA and Web Services. Of course, this has nothing to do with Service-Oriented Architecture, as we’ve discussed in numerous ZapFlashes in the past. The power of SOA is in loose coupling, composition, and how it enables approaches like Cloud Computing. It is for these reasons that I chose to adopt SOA for a project I’m currently working on. But when I needed to implement the Services I had already determined were necessary, I faced a choice: use Web Services or REST-based styles as the means to interact with the Services. For the reasons I outline below, REST was a clear winner for my particular use case.

Web Services in Theory and in Practice

The main concepts behind Web Services were established in 1999 and 2000 during the height of the dot-com boom. SOAP, then known as the Simple Object Access Protocol and later just “SOAP,” is the standardized, XML-based method for interacting with a third-party service. Simple in concept, but in practice, there’s many ways to utilize SOAP. RPC style (we think not) or Document style? How do you identify end points? And what about naming operations and methods? Clearly SOAP on its own leaves too much to interpretation.

So, this is the role that the Web Services Description Language (WSDL) is supposed to fill. But writing and reading (and understanding) WSDL is a cumbersome affair. Data type matching can be a pain. Versioning is a bear. Minor server-side changes often result in different WSDL and a resulting different Service interface, and on the client-side, XSD descriptions of the service are often similarly tied to a particular version of the SOAP endpoint and can break all too easily. And you still have all the problems associated with SOAP. In my attempts to simply get a Service up and running, I found myself fighting more with SOAP and WSDL than doing actual work to get Services built and systems communicating.

The third “leg” of the Web Services concept, Universal Description, Discovery and Integration (UDDI), conceptually makes a lot of sense, but in practice, hardly anyone uses it. As a developer, I couldn’t even think of a scenario where UDDI would help me in my particular project. Sure, I could artificially insert UDDI into my use case, but in the scenario where I needed loose coupling, I could get that by simply abstracting my end points and data schema. To the extent I needed run-time and design-time discoverability or visibility into Services at various different states of versioning, I could make use of a registry / repository without having to involve UDDI at all. I think UDDI’s time has come and gone, and the market has proven its lack of necessity. Bye, bye UDDI.

As for the rest of the WS-* stack, these standards are far too undeveloped, under implemented, under-standardized, inefficient, and obscure to make any use of whatever value they might bring to the SOA equation, with a few select exceptions. I have found the security-related specifications, specifically OAuth, Service Provisioning Markup Language (SPML), Security Assertion Markup Language (SAML), eXtensible Access Control Markup Language (XACML), are particularly useful, especially in a Cloud environment. These specifications are not Web Services dependent, and indeed, many of the largest Web-based applications use OAuth and the other specs to make their REST-based environments more secure.

Why REST is Ruling, and Applying SOA Principles

I ended up using REST for a number of reasons, but the primary one is simplicity. As most advocates of REST will tell you, REST is simpler to use and understand than Web Services. Development with REST is easier and quicker than building WSDL files and getting SOAP to work and this is the reason why many of the most-used web APIs are REST-based. You can easily test HTTP-based REST requests with a simply browser call. It can also be more efficient as a protocol since it doesn’t require a SOAP envelope for every call and can leverage the JavaScript Object Notation (JSON) as a data representation format instead of the more verbose and complex to process XML.

But even more than the simplicity, I appreciated the elegance of the REST approach. The basic operation and scalability of the Web has proven the underlying premise of the fundamental REST approach. HTTP operations are standardized, widely accepted, well understood, and operate consistently. There’s no need for a REST version of the WS-I. There’s no need to communicate company-specific SOAP actions or methods – the basic GET, POST, PUT, and DELETE operations are standardized across all Service calls.

Even more appealing is the fact that the vendors have not polluted REST with their own interests. The primary driver for Web Services adoption has been the vendors. Say what you might about the standard’s applicability outside a vendor environment, one would be very hard pressed to utilize Web Services in any robust way without first choosing a vendor platform. And once you’ve chosen that platform, you’ve pretty much committed to a specific Web Services implementation approach, forcing third-parties and others to comply with the quirks of your particular platform.

Not so with REST. Not only does the simplicity and purity of the approach eschew vendor meddling, it actually negates much of the value that vendor offerings provide. Indeed, it’s much easier (and not to mention lower cost) to utilize open source offerings in REST-based SOA approaches than more expensive and cumbersome vendor offerings. Furthermore, you can leverage existing technologies that have already proven themselves in high-scale, high-performance environments.

REST: Focus on Architecture, Not on HTTP

So, how did I meld the fundamental tenets of SOA with a REST-based implementation approach? In our Web-Oriented SOA ZapFlash, we recommended using the following approach to RESTafarian styles of SOA:

  • Make sure your Services are properly abstracted, loosely coupled, composable, and contracted
  • Every Web-Oriented Service should have an unambiguous and unique URI to locate the Service on the network
  • Use the URI as a means to locate as well as taxonomically define the Service in relation to other Services.
  • Use well-established actions (such as POST, GET, PUT, and DELETE for HTTP) for interacting with Services
  • Lessen the dependence on proprietary middleware to coordinate Service interaction and shift to common Web infrastructure to handle SOA infrastructure needs

Much of the criticism of REST comes not from the interaction approach, but rather from the use of HTTP. Roy Fielding, the progenitor of REST, states in his dissertation that REST was initially described in the context of HTTP, but is not limited to that protocol. He states that REST is an architectural style, not an implementation, and that the Web and the use of the HTTP protocol happens to be designed under such style. I chose to implement REST using eXtensible Messaging and Presence Protocol (XMPP) as a way of doing distributed, asynchronous messaging styles of REST-based Service interaction. XMPP, also known as the Jabber Protocol, has already proven itself as a widely-used, highly-scalable messaging protocol for secure and distributed near-realtime messaging protocol. XMPP-based software is deployed widely across the Internet, and forms the basis of many high-scale messaging systems, including those used by Facebook and Google.

Am I bending the rules or the intent of REST by using XMPP instead of HTTP? Perhaps. If HTTP suits you, then you have a wide array of options to choose from in optimizing your implementation. Steven Tilkov does a good job of describing how to best apply HTTP for REST use. But you don’t have to choose XMPP for your implementation if HTTP doesn’t meet your needs. There are a number of other open-source approaches to alternative transports for REST existing including RabbitMQ (based on the AMQP standard), ZeroMQ, and Redis.

The ZapThink Take

The title of this ZapFlash is a bit of a misnomer. In order to be a convert to something you first need to be indoctrinated into another religion, and I don’t believe that REST or Web Services is something upon which to take a religious stance. That being said, for the past decade or so, dogmatic vendors, developers, and enterprise architects have reinforced the notion that to do SOA properly, you must use Web Services. ZapThink never believed that this was the case, and my own experiences now shows that SOA can be done well in practice without using Web Services in any significant manner. Indeed, my experience shows that it is actually easier, less costly, and potentially more scalable to not use Web Services unless there’s an otherwise compelling reason.

The conversation about SOA is a conversation about architecture – everything that we’ve talked about over the past decade applies just as equally when the Services are implemented using REST or Web Services on top of any protocol, infrastructure, or data schema. While good enterprise architects do their work at the architecture level of abstraction, the implementation details are left to those who are most concerned with putting the principles of SOA into practice.

Discussion

17 comments for “How I Became a REST “Convert””

  1. Excellent article, Ron. Can’t wait to hear your and ZapThink’s take on the enterprise API governance industry (SOA Software’s Atmosphere and Layer7 look to be the vanguard, though most haven’t yet realized that REST/Doc, not SOAP/RPC, is the major players outside the enterprise), the public players (Mashery, Apigee, etc.) and of course Google with their jsonschema-based next gen API.

    Also, what do you think of unREST

    http://www.ebpml.org/blog2/index.php/2011/06/29/unrest
    http://www.infoq.com/news/2011/07/unrest

    - H / lza2010

    Posted by G. Hussain Chinoy | July 12, 2011, 9:47 pm
  2. How are you doing contracts with REST? What is the REST equivalent of WSDL?

    Posted by Greg Newton | July 17, 2011, 8:07 pm
    • The question for you is how are you leveraging the contracts? In the Web Services mindset, design-time and run-time use of contracts are one and the same. For REST, you can separate the idea of contracts as intended for human consumption from those intended for system consumption. In which case, you can use divergent approaches, such as Wikis for the former and HATEOAS type approaches for the latter.

      Posted by Ronald Schmelzer | July 19, 2011, 12:27 pm
  3. I think it’s very interesting and exciting that you were able to leverage XMPP for this system and help separate REST from HTTP.

    But I’m curious if and how you applied hypermedia for your application, and what kinds of media types were involved.

    Posted by Will Hartung | July 19, 2011, 12:16 pm
    • I use JSON in the exchange between Service consumers and providers, and if you leverage the HATEOAS approach, you can embed a ‘link’ return value that provides next-step or follow-up queries. For XMPP, instead of thinking in terms of URL for hyperlinks, think in terms of message “topics”. Also, think of REST in a transport Neutral way. I can still send GET and POST requests on XMPP and use resource-oriented paths (/orders/ for example) and broadcast it onto an XMPP chat room to achieve a pub/sub approach or to a specific XMPP peer.

      Posted by Ronald Schmelzer | July 19, 2011, 12:30 pm
  4. The notion of contracts and REST are alien to each other.

    If your services have well defined contracts then they are not part of REST.

    Contract implies tight coupling which REST is suppose to avoid. Note that just because a contract is not defined explicitly (in a WSDL) it does not mean that a contract does not exist.

    In order to avoid contracts (i.e. reduce dependence on out-of-band information) REST mandates the use of standard media types only that clients should handle in a generic way. Clients should not rely on application specific data formts (be it JSON or XML).

    I think we need to come up with a new name for web-style interactions (Web API?) so that we don’t keep confusing with REST. Then we can have a more intelligent conversation.

    Posted by Faisal Waris | July 19, 2011, 3:00 pm
    • This seems like a fairly intelligent conversation to me.

      Posted by Ronald Schmelzer | July 19, 2011, 3:23 pm
    • I’m new to REST and I’m having trouble wrapping my head around this.

      There is no defined schema/stucture for the data?

      So if I call a Netflix service to get information about a movie, I don’t know ahead of time what fields Netflix is going to give me?

      Posted by Todd Hensley | July 21, 2011, 2:33 pm
      • Not programatically, but that’s what documentation is for. Even if it was automatic (through a schema or contract), a human would still have to read it. Most RESTful APIs have a wiki or similar documentation site to accompany the actual API call. You’d probably have to go there to get the API key anyways. But no, there’s no established way to return schema or contract information for a RESTful service, unless you created one yourself. I’m not sure it would be worth the time above and beyond a Wiki given the way people are consuming Services these days.

        Who knows, it’s just my opinion, but I’m having a great time and great success using REST where Web Services (SOAP and WSDL) were a freakin’ bear. I don’t feel like I’m having to sacrifice any of the architectural goals or productivity by doing that. Keep experimenting and do what works for you!

        Posted by Ronald Schmelzer | July 21, 2011, 2:41 pm
      • Todd,

        There isn’t a programmatically discoverable schema or methods (RPC). For a lot of REST services, you must physically read the documentation to determine the format of the payload and the URI schemes that either define the objects (and use the HATEOS principle for REST/Document interaction) or the methods (for REST/RPC interactions).

        Does that help?

        Posted by G. Hussain Chinoy | July 21, 2011, 2:46 pm
        • Yeah, but I find it disappointing. I actually LIKE machine-readable schemas for the payloads. This seems like a step backward to me.

          Posted by Todd Hensley | July 21, 2011, 3:54 pm
          • I agree, and I think a convention will emerge that can be codified (something like using HTTP/1.1 OPTIONS on a URI for an object to return its jsonschema or what Google’s doing with its Discovery API: http://code.google.com/apis/discovery/v1/getting_started.html).

            Until then, REST APIs force more engagement between API providers & consumers, which isn’t a bad thing!

            Posted by G. Hussain Chinoy | July 21, 2011, 4:08 pm
    • I disagree that the notion of REST and contracts are alien to each other. I’d argue that the straightforward quality attributes of REST returns the conversation to the discussion of what a contract is and how should it be defined.

      An autogenerated WSDL is markedly not a service-oriented contract, it’s a web functionality interface description that is conflated to be used as a contract.

      Additionally, there are principles that REST is based upon (state, not methods, since methods are in the transport).

      There are definitely areas of formality, compared with SOAP & WS-*, that are not in current day REST implementations, though. There’s no absolute agreement as to what the HTTP verbs should mean or how best to apply HATEOS. There’s no good way to define and discover/implement schemas (even jsonschema’s only one half of that).

      I’m of the opinion that REST is actually a step forward in that it allows composable services to be built rapidly therefore iterating on the concept of SOA and continuing the conversation that stagnated when tooling around WSDL/SOAP/WS-* became all the rage.

      Posted by G. Hussain Chinoy | July 21, 2011, 2:55 pm
  5. REST is easier if you’re hand coding. If you’re using a tool set that generates the code, web services are better because the tools examine the WSDL and generate everything you need. And yes, the suite I’m using generates solid, reliable code every time. I like to get computers to do as much grunt work as possible – isn’t that why we invented them?

    Posted by Greg Newton | August 6, 2011, 4:32 am
  6. [...] How I Became a REST “Convert” | ZapThink http://www.zapthink.com/2011/07/12/how-i-became-a-rest-convert/ [...]

    Posted by REST: Links, News and resources (2) « Angel “Java” Lopez on Blog | September 28, 2011, 6:05 am
  7. It is not a zero/sum game.

    It’s NOT REST or SOAP it is REST AND SOAP. I love when these guys “discover” REST and say I am going REST all the way baby. That is until they find out about REST’s performance issues or weak security model….

    Posted by DOTNETGUY | June 26, 2013, 7:58 am
    • You can certainly support SOAP messages within a RESTful approach. WSDL 2.0 has a REST binding — but few people use WSDL 2.0, so that may not help. But there has been a SOAP Internet Media Type defined for over a decade now. That being said, SOAP is not well-suited for hypermedia interactions, so it leaves much to be desired when implementing REST.

      Posted by Jason Bloomberg | June 26, 2013, 8:04 am

Post a comment

FREE POSTERS

NEW VERSION! ZapThink's Vision for Enterprise IT in 2020
With all new content including Dev/Ops, Hypermedia-Oriented Architecture, Big Data Visualization, and more!
Click here to download for FREE
10-pack of prints for only the cost of shipping!

SOA Implementation Roadmap
Over 100,000 downloaded!
Click here to download for FREE
10-pack of prints for only the cost of shipping!