RESTful Myths: Unraveling the Confusion
Shame on me for not delving into this deeper, sooner. It was high time I took on some of the myths in the REST community again.
First let me say that I like REST. I think the architecture makes a lot of sense in many cases and I look forward to implementing my first RESTful services(s). Having said that the REST community don't do themselves many favors with the enterprise community, especially those that have been around the block several times and have built several flavors of architectures over the years. We know our architectures -we know our terminology. It seems the REST guys confuse some terms. So I'm going to target some areas to help unravel the muddle.
I've decided to base this critique on the new popular book RESTful Web services by Richardson & Ruby. I'm assuming that the REST community stand by this book - otherwise, sadly, it just adds some more confusion. To the authors I say thank you, I'm enjoying the book. Don't think I don't like it just because of this blog. It has not only helped me appreciate some of the confusion in the industry but it has helped me to appreciate the RESTful resource oriented approach.
Before I start I'll summarize by saying this. Perhaps much of the present confusion is that the REST community has changed the semantics of some popular enterprise computing terminology. We shall address these below.
Myth # 1: (from page 19) "All Web services are message-oriented, because HTTP itself is message oriented." One could argue, in a very loose way, that HTTP is message oriented but it's a bit like saying that airplanes are "ground transport" just because they can travel on the ground. Modern convention says that airplanes are air transport. Modern, popular conventions says that message oriented is asynchronous not synchronous. HTTP is a synchronous transport. Message Oriented Middleware (MOM) is a class of technology that includes JMS, MQ Series, CORBA's Event Service, etc. Generally regarded as connectionless technology. So though one could regard HTTP as message oriented in some general english language sense, those in the industry a long time would not call HTTP "message oriented". HTTP is a connection based, synchronous technology. Nothing wrong with that but it is interesting considering some of the later myths which criticize RPC style technology, where WS-* is singled out.
Myth # 2: REST is not RPC and RPC is in some way bad. When reading this book and watching or participating in discussions on REST there is implicit and explicit criticism of RPC based approaches. But again there is confusion here. The REST folk mean that having an explicit operation/method name in a message or in the invocation is what is meant by RPC. However there are two or three ways that this argument doesn't work and is confusing.
- Again a terminology confusion. Most people, that have been in the industry for some time, usually refer to RPC when talking about synchronous, connection based communication. The emphasis is on that rather than a rich vocabulary of method names - though that is part of the assumption.
- HTTP is an RPC model. It's synchronous and connection based. Moreover, it has a relatively rich set of remote procedure vocabulary - POST, PUT, GET, DELETE being some of them. Question: So if someone using CORBA used DII and had an interface with only three or four generic operations like HTTP, would that make it RESTful?
Myth # 3: REST makes things simpler by having a uniform generic interface. There are two ways to approach this. Again I'd put the example of MOM based communications (e.g. JMS), or DII in CORBA. All of these technologies have a uniform interfaces. CORBA has invoke, send_oneway, send_deferred,etc. JMS has publish. Does a uniform interface then make it simpler? Not necessarily because then the application code needs to have more smarts in it for marshaling and message validation etc. The static interfaces defined by using CORBA IDL based proxies or Java interfaces with RMI helped remove this extra work "Let the middleware worry about that," was a reason to use such things. But this is not pure enough for REST. But for most Web facing applicaitons REST works great! But wait a minute, what's this? From page 25: "Instead, as a smart programmer you'll quickly notice the patterns underlying your requests to a given service, and write wrapper methods that abstract away the details of HTTP access." Surely not! Surely this is blasphemy! Could the RESTful be advocating some sort of wrapper proxies? Sounds like it. Hmmmm .... I've said this before in a blog entry called I've been arRESTed! HAving said that I had far less a clue about REST then than I do now.
So some questions for the REST folks:
If I was using JMS and had a different queue defined for each resource and had four messages defined: add, delete, update, and get, and I sent XML payloads using these queues, is that RESTful? By definition it would seem that it is.
I have to conclude the following, just as the REST folks say that Web services and SOAP is hijacked by WS-*, is REST hijacked by HTTP? (In fairness the book does not give out to much about SOAP just the way that most implementations use SOAP.) I mean can RESTful services be implemented using another transport? And can a uniform interface have operations similar but different to HTTP's POST, PUT, DELETE and GET? Is it okay if they map to CRUD?
What about a service where the semantics of HTTP verbs aren't enough? Is REST only useful in it's purest RESTful way for resources that basically only have CRUD interface? What about objects that have richer semantics? Does the semantics (and therefore the verb) get hidden in the data of a PUT? (And therefore break the rules) Or do we have to define more finer resources in order to fit the REST model?
Now at the start I made it clear that I like REST. I do! In fact I think it is really neat. I think it has lots of applications. Again I look forward to implementing a resource oriented architecture using REST. And I'll do it just like Richardson and Ruby suggest. It makes sense.
The bottom line is that REST is a really cool HTTP based and CRUD based architecural style that works great for web based applications. It makes one more interface assumption that helps it a great deal - It assumes that most data is text and so lots of the ugly marshalling issues that would push you towards using other technologies go out the window. You don't need them and therefore REST makes sense. So it makes communiction simple and then you can rely on high speed processors to do any marshalling into various binary types that you might be using in your application code. Again nothing wrong with this for a great deal of applications.
My challenge is that the REST community work with the other communities, including WS-* (the REST community has cute nicknames for this community) to help clear up some of the confusion - and I think some are trying. For example I don't think it's fair to assume that Web services is just HTTP. HTTP is successful for a number of reasons and not just the fact that it has a simple, uniform interface. Remember most enterprise architects got stuck with HTTP because web administrators didn't like opening up lots of ports - no matter how secure the alternative transport/protocol might be. As a result people were doing ugly things like tunneling through HTTP to do B2B. As a result we just had to resign ourselves to the fact that HTTP was the "Web" when it came to outside the firewall. But there is no reason that alternative approaches cannot be used, especially behind the firewall.
And so I think it is important to define some boundaries to where REST works really well and where it doesn't. Let's be honest about it an not have so many ideological wars. REST is really really useful ... so are other approaches.
My expectation is that the response I'll get to this is "he just doesn't get it!" coupled with the "REST can do everything" answer instead of some clarification, some constructive suggestion on how the REST community can be more inclusive while at the same time remaining RESTful, and some best practices. This would not only do a good service to the larger community, as the RESTful Web services book has done a good service educating me, but it would also help the REST community itself because, as the book points out, most REST implementations are not RESTful but "REST-RPC" based. So there is plenty of confusion currently and room for improvement.
I'm not claiming to be a REST expert. I'm not claiming REST is bad. I just want some honest debate and less confusion around the terms. There is a danger that REST might "go to rest" because there is confusion and disagreement. I hope to learn more about REST as I continue to read the book (no doubt some of the above questions are answered in sections I haven't reached yet.)
IP Babble is the personal blog of
Comments
William, you're being way too mature about this. Where is your ideological zeal? Why not jettison tired approaches that have run their course and adopt wholesale the Next New Thing?
Posted by: Jody Hunt | July 17, 2007 07:12 AM
"Again I'd put the example of MOM based communications (e.g. JMS), or DII in CORBA. All of these technologies have a uniform interfaces."
Bill, that's just not true. REST requires that the *application operations* be uniform. "invoke" isn't RESTful because it isn't an application layer operation; what *method* is invoked is the application layer operation.
e.g. invoke(getStockQuote("GOOG")) isn't uniform, while invoke(GET("http://example.org/quotes/GOOG")) is.
Posted by: Mark Baker | July 17, 2007 08:50 PM
Hi Mark,
Thanks fot the comment. I knew I could rely on you ;-)
First, it's William, thanks.
Sure it is. One could simply set up a different IOR for each resource and have :
request_.invoke(GET(GOOG));
Just as you pointed out. invoke in DII is very uniform infact. It's the static interfaces defined in IDL that make it unRESTful. But you'd argue correctly that that was not what CORBA was designed for - and you'd be right. But it dodn't stop some people form implementing interfaces that way. I believe that was bad. CORBA IDL was developed for richer semantics in IDL and should have been used that way. One can argue that CORBA was a bad technology if one wants to but when using it one should take advantage of it's capabilities and use it as intended.
I'm going to make another entry on RPC in the next one because I need to clear things up.
Posted by: William | July 17, 2007 10:43 PM
Oops, sorry William. I forget which of my William friends like to go by Bill, and which don't! You guys should get together and standardize 8-)
If you've got a getStockQuote method, you're not uniform whether you invoke it via DII, or via stubs generated from IDL. If you've got a GET method, then you are uniform whether you use DII or not.
Posted by: Mark Baker | July 18, 2007 06:57 AM
Hi Mark,
Right.
I would say that if using CORBA, with its marshaling capabilities and type mappings, one would not use this approach. I think it's a waste of CORBA.
So if it's a uniform interface you're looking for then use some other technology - perhaps RESTful HTTP if possible or RESTful MOM if possible.
Posted by: William | July 18, 2007 07:09 AM
Mark your comment about uniform interfaces makes it sounds as there's never any method anywhere in the picture, which just can't be true. At some point the message needs to be processed, and to do that has to be dispatched to a method, or invoke a method on an object. It seems like what you're arguing about is where the method is visible, and to whom, rather than whether or not a "non uniform" method exists somewhere since it must if the message is to be consumed by an application (rather than a person, who in HTML stands in for the "custom method").
Posted by: Eric Newcomer | July 18, 2007 08:17 AM
Hey Eric.
A non-uniform method may exist somewhere in the chain of software that "makes stuff happen", it's just that it's not part of the contract between client and server. What is, in a RESTful system, is the uniform operations (and other stuff too of course).
So the server may have some logic which includes a getStockQuote() invocation, but so long as there's an HTTP facade in front (with the URI properly wired to the quote impl) all the client knows is that it's invoking GET.
It's polymorphism in action; just as draw() can call drawCircle() or drawRectangle() without the client knowing about circles or rectangles, so can Web clients call GET and see what comes back from getStockQuote or getLastOrder or ...
Posted by: Mark Baker | July 18, 2007 03:41 PM
Coming from the enterprise software world, I take issue with some of your claims here.
1. Your first claim, that "message oriented" implies connectionless, isn't what i would call modern convention. It really depends of the context of the term's usage.
When speaking about _middleware_, then yes, it is assumed to exchange messages in a variety of patterns, and to ensure those messages are delivered reliably.
But, generally message orientation, in my experience, really just implies the application abstraction in use: it means that one is working with a messaging application model, as opposed to a procedure call model, or a relational datastore model.
It does not help matters to confuse an application model with the timing constraints on a protocol. For example, While HTTP is a synchronous transport, many "messaging oriented middleware" infrastructures use a synchronous transport, whether WS-ReliableMessaging over HTTP, or WebSphere MQ over TCP. In fact, some reliable messaging middleware actually uses HTTP under the covers!
I have seen the term "MQ" used quite a bit as a general term for connectionless, message-oriented systems, however, even when they're not using IBM's famous product.
2. Regarding RPC, again, this is not my experience of how the industry uses the terminology, at least when making a serious evaluation of a system!
RPC is a networked application model where the abstraction is as close as possible to the procedural programming model. It falls out of this that the network communication is by nature synchronous, but it would be very sloppy to just equate RPC = synchronous communication.
The focus of RPC is "transparency": to make network programming as similar as possible to programming on a local machine.
It is this fallacy of distributed systems transparency has been highlighted loudly and widely in many corners, and is why RPC has been widely panned long before REST ever became a twinkle in Roy Fielding's eye - from Jim Waldo's 1994 paper, to Peter Deutsch's 7 fallacies of distributed computing.
HTTP is not an RPC model because it does not attempt to make the network transparent to the programmer, or even the user. Given the many models there are to implement HTTP (from Servlets to ASP.NET to Ruby on Rails), I'd say that it clearly is not RPC.
SOAP 1.2 is a general purpose extensible network protocol, and not necessarily RPC-based. WSDL has, on the other hand, traditionally confined the use of SOAP into a very RPC-oriented manner (leading to interoperability weirdness like "doc-literal-wrapped", requiring unique global element declarations in a SOAP body, etc.).
As to your further discussion.
a. REST isn't really CRUD based. HTTP isn't either. "POST" does not fit into "CRUD", it means "process this".
b. The uniformity of REST is not about the methods being constrained. That's a sideshow, one that we focus on too much because of how HTTP implemented REST.
The rest of my reply is on my blog entry - http://www.stucharlton.com/blog/archives/000154.html
Posted by: Stu Charlton | July 26, 2007 06:57 PM
Hi Stu,
Please see my next post:
http://www.ipbabble.com/2007/07/more_restful_clarit.html
In here I go into more detail about Message Oriented and RPC.
RPC is Remote Procedure Call. And though the idea is to provide an easier mechanism for doing this - abstracting much of the hard work of the network. The original paper (RFC 707) warns that (at least heavily implies) that some differeniation between local and remote calls should be made.
I agree that many Message Oriented technologies often use synchronous technologies. Only technologies like broadcast and multicast are "connectionless". But popular semantics for things like pub/sub describe them as asynchronous and non-blocking from an application perspective.
Posted by: William | July 26, 2007 11:36 PM
Hi William,
I saw the post after I wrote my prior comment. Thanks.
One area where I agree is that popular semantics refer to pub/sub as "asynchronous" and "non-blocking". But this is an area where popular semantics is misleading and confusing, because there's a distinction between asynchronous I/O and asynchronous communication.
For example, it's increasingly common to see synchronous network communication over, asynchronous (non-blocking) I/O implementations implemented via the select() call in UNIX, or I/O completion ports in Windows, or the java.nio.* feature set. Here we could have a synchronous communications protocol (HTTP over TCP) implemented on top of an asynchronous I/O subsystem.
Asynchrony, particularly in terms of performance and scalability, is more determined by how your code interacts with the network than the wire protocol itself.
Posted by: Stu Charlton | July 30, 2007 02:28 PM