BT

RPC or REST in the Cloud?

by Mark Little on Feb 13, 2011 |

In a previous article we discussed William Vambenepe's question of whether or not REST is really important for the Cloud when the front runner in that area does not use it? After our posting William had further feedback, which promoted him to try to clarify further as others continued to ignore, or not see, the central idea running through his original entry: that for developers, separated from the underlying interaction mechanism by language constructs such as objects or RPC, whether or not that approach is implemented using REST is likely to be immaterial. As William states:

Method calls is how normal developers write normal code. Doing it over the wire is the smallest change needed to invoke a remote API. The complexity with RPC has never been conceptual, it’s been in the plumbing. How do I serialize my method call and send it over? CORBA, RMI and SOAP tried to address that, none of them fully succeeded in keeping it simple and yet generic enough for the Internet. XML-RPC somehow (and unfortunately) got passed over in the process.

As he points out, AWS uses an approach that is very similar to XML-RPC. They made some trade-offs in their approach, but in general Amazon took a very pragmatic point-of-view and ended up with something that is conceptually simple and yet powerful (and usable). However, it seems that many people still disagree, such as Mike Pearce, who states that ...

I know I’m a RESTafarian (so coined for people who have an unhealthy enjoyment of REST), but really, Amazon haven’t proven anything, other than being arrogant and disrespecting developers.

In William's recent posting he attempts to address all of Mike's concerns. For instance, when Mike asks the question:

Does the fact that AWS use their own implementation of an API instead of a standard like, oh, I don’t know, REST, frustrate developers who really don’t want to have to learn another method of communicating with AWS?

To which Mike responds in the affirmative, but which promts William to counter with ...

I scratch my head. I’ve met many developers struggling to understand REST. I’ve never met a developer intimidated by RPC. As to the claim that REST is a “standard”, I’d like to read the spec. Please don’t point me to a PhD dissertation.

According to William, the point isn't whether or not REST is important for the evolution of the Cloud, but really whether the Cloud has evolved to a point where it is necessary or would make a substantial difference (to developers or implementers). In William's view, the benefits of REST in a single vendor offering, are likely to be limited.

The usage patterns for Cloud APIs may evolve to the point where the benefits of following the rules of REST become compelling. I just don’t think we’re there and frankly I am not holding my breath. There are lots of functional improvements needed in Cloud services before the burning issue becomes one of orchestrating between Cloud providers. And while a shared RESTful API would be the easiest to orchestrate, a shared RPC API will still be very reasonably manageable. The issue will mostly be one of shared semantics more than protocol.

There are also disagreements about William's premise that the use of REST is hidden behind programmatic interfaces so does it really matter at that level anyway? But as one commenter on his original article states:

The vast majority of AWS (or any cloud provider’s) users never see the API. They interact through language libraries or via web-based client apps. So, the only people who really care are RESTafarians, and library developers (like me). Perhaps it’s possible to have an API that’s so bad it prevents people from using it but the AWS Query API is no where near that bad. It’s fairly consistent and pretty easy to code to. It’s just not REST. It’s also worth noting that not all of AWS is in this boat. S3, CloudFront and Route53 API’s are much more RESTful.

The overall theme running throughout William's recent posting is that a good developer interface can hide a non-REST API approach and still be useful, whereas the inverse is not necessarily the case. The combination of a good interace and REST beneath may be the nirvana that the industry will achieve eventually, but at this stage it is neither a necessary nor sufficient condition for the success of Cloud. Getting the semantics of your resources right, as well as the programmatic interfaces, including error handling, is probably more important to Cloud developers than the best RESTful interfaces.

If your RPC API is consistent enough that its underlying model could be used as the basis for a REST API, you’re probably fine.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Seems like a pointless debate. by Richard Clayton

Why not both? While REST is not a standard, conceptually, it provides a great metaphor for interacting with resources. *-RPC is easy to implement and in my opinion makes more sense from a "service" perspective (behaviorally, e.g.: as in performing actions). The fact of the matter is, since neither 'style' of web service is self describing, most companies have provided clients. I think William is right when he comments:

"The vast majority of AWS (or any cloud provider’s) users never see the API. They interact through language libraries or via web-based client apps. So, the only people who really care are RESTafarians, and library developers (like me)".

So topics like "RPC or REST in the Cloud?" are ridiculous because they intentionally incite "flame wars" because the reasoning is fundamentally flawed. Why can't both exist? This Highlander. There can be more than one!

Re: Seems like a pointless debate. by Richard Clayton

Wow, it's early in the morning, so please forgive my terrible English. I meant to say: This isn't Highlander, there can be more than one!

The very term REST API is an oxymoron by Faisal Waris

The main goal of Fielding was network applications that are "contract free". Ideally, RESTful clients should not be affected by changes in the resource model. In practice this is very hard to achieve.

For example, when a client does an HTTP GET it should "discover" what it received via the content type (and some high level metadata) and know how to treat the content (late binding). The client should not expect (or depend upon receiving) a specific data structure for the response (early binding).

In practice most (all?) REST apis require early binding - throwing away the very essense of REST.

Will we every achieve proper RESTful applications at a wide scale? The evidence thus far is not very reassuring.

If you can a nice accessible service, then do both by Hiram Chirino

Build a REST API which is easy to access in an RPC style. Projects like RestyGWT can help rich clients access those rest services like if they were RPC services.

For the cloud service or for the service in the cloud? by Steven Pena

Success of the cloud doesn't necessarily depend on the API of the service provider. Any good developer should be able to consume a REST or RPC-style service without much issue when deploying and managing their cloud-based service/app.

However, the success of the cloud WILL depend heavily on REST implementations of services running IN the cloud. Companies seeking to gain maximum adoption of their services will need to support as many clients as possible (phones, desktops, other servers/services). REST is more suitable for these various clients (especially the fastest growing segment - phones). As their services gain adoption so will their need for the benefits of a cloud-based infrastructure.

Re: For the cloud service or for the service in the cloud? by Richard Clayton

How is REST more suitable for these clients?

Re: For the cloud service or for the service in the cloud? by Jean-Jacques Dubray

REST never existed, it is just a No-WS* movement who suggests to hand code services calls and has no interface definition language.

Re: For the cloud service or for the service in the cloud? by Steven Pena

It's more suitable for these clients largely in part to the transport it prescribes - it is smaller, lightweight, and doesn't require an additional framework (just needs a basic HTTP stack). A SOAP payload carries with it additional information that causes the message to be bulkier and require more processing to de-serialize. For clients like a mobile device, these two factors are critical. Javascript as well has an easier time dealing with REST. All the popular JS frameworks have built in support for JSON and AJAX calls to interact with these services (jQuery for example). Not too many (can't think of any off the top of my head) have support for SOAP. Additionally, clients utilizing a compliant HTTP framework can take advantage of the protocol without any additional effort as well. Concerns like caching and content negotiation can be addressed without any development from the client app.

The other large factor towards suitability (not necessarily for the client per se) is the primary responsibility of most public services will be surfacing data. As such, adopting a common set of standards for querying and modifying that data will go a long way towards adoption.

The more obstacles you can remove from your consumers the more suitable the solution. Look at some of the most popular services that have the greatest adoption (Facebook, Twitter, Google's services, any RSS feed) - they are all based on a REST-style.

My main point was to highlight the difference between an API to manage a service in the cloud vs. an API for that service. These are two very different animals. The latter is much more relevant to the success (which I'm defining as adoption) of a style than the former. There are much more clients using services like Facebook, Twitter, Google, and RSS feeds than Amazon's API to manage services.

Re: For the cloud service or for the service in the cloud? by Steven Pena

REST never existed? I guess the Web never existed either then. The very notion of hyperlinks, web pages surfaced via GETs, updates sent to servers via POSTs, pretty much everything driving your Web browsing experience are REST.

Re: For the cloud service or for the service in the cloud? by Jean-Jacques Dubray

Let me qualify, from a distributed computing perspective (what I often call the "other" REST, and the one we are talking about in this post).
REST from a User-Browser-Server perspective is of course pretty much everywhere, at least for now.

Re: For the cloud service or for the service in the cloud? by Richard Clayton

Steven,

You are only reaffirming my point. I'm not advocating SOAP. What I'm saying is that RPC requires the same kind of infrastructure as REST. You have to define some sort of schema for your data (though that schema is not self-describing like SOAP) and conventions for accessing that data. REST uses the URL as a metaphor for a "tree" of resources. RPC may use URL or POST parameters. Neither one are technically better than the other, developers just have their own philosophical preferences. The point is, there is plenty of room for either in the cloud. Engineers/Bloggers need to stop using absolutism in describing the options: "RPC or REST in the Cloud?". Both can exist, both are completely valid, just as SOAP is still a vital and valid web service technology in the cloud. My complaint is that someone nontechnical is going to read this and think you can only have one.

Rich

Message-based vs. RPC by Bill Burke

I've been diving into REST for a few years now and what it does, IMO, is makes you think in more of exchanging messages rather than doing an RPC protocol. Message based interactions, IMO, are much more flexible and maintainable over time as its much easier to piggyback contextual information or additional data than an strict (and brittle) RPC-based approach. IMO, I don't think message-based interfaces are much of a leap for RPC developers. Get them thinking in that manner, and you can introduce RESTful principles over time.

Folks, REST is a set of principles applied to a protocol, not a protocol in and of itself. You could apply RESTful principles to CORBA, SOAP, JAX-RPC, XML-RPC, RMI, whatever...

Re: For the cloud service or for the service in the cloud? by Steven Pena

I'm not sure I understand how this re-affirms your point. How does SOAP compare against those benefits I listed to your question?

REST isn't about defining a schema and can even care less about how the URL maps to a metaphor. I'm further confused by your comparison between the two...

Re: For the cloud service or for the service in the cloud? by Richard Clayton

Steve, I wasn't talking about SOAP. RPC is not SOAP (RPC is more commonly referred to as XML-RPC or JSON-RPC). I clearly said:

I'm not advocating SOAP. What I'm saying is that RPC requires the same kind of infrastructure as REST.


RPC is Remote Procedure Call. Think using URL parameters/scheme to access a resource or call a service: en.wikipedia.org/wiki/Remote_procedure_call. My point is: REST does not offer any technical benefit over RPC. Notice how I did not once mention SOAP.

You said:

the success of the cloud WILL depend heavily on REST implementations of services running IN the cloud.


Why would the success of the cloud be hindered by RPC? Amazon is using RPC and it is one of the largest PAAS and SAAS clouds in the world.

I think ODATA is the best approach by Faisal Waris

I think oData offers the best approach as it allows for early or late binding.

There is metadata that describes the service interface relatively cleanly. The interface is mostly data oriented (somewhat like SQL over HTTP) but can offer operations if needed.

You can use json seraialization for performance.

Supported .Net, Java and javascript now (don't know about others such as Ruby)

Re: I think ODATA is the best approach by John Ruiz

This is another example of what Richard is driving at; one cannot say
I think oData offers the best approach
unless it is followed by, "given all the requirements, constraints, and goals of my individual situation."

There tends not to be a uniform "best" that covers all scenarios. There is no silver bullet.

Elegant, supple architectures require close attention to the trade-offs involved in every decision.

Therefore, my answer to the question "REST or RPC in the cloud" is: MU. The question is not answerable as posed.

Re: I think ODATA is the best approach by Faisal Waris

Agree with you up to a point.

Generally, we look for abstractions and apply these to large swath of similar problems.

In my opinion oData provides a decent set of abstractions for typical cloud communication patterns.

Granted, there will be situations where oData is not a good fit.

Re: Message-based vs. RPC by John Ruiz

Bill Burke of RESTEasy? When you say "diving into REST", I think you sell yourself short! I caught your presentation in Boston last summer and really enjoyed it.

I don't think you're wrong - and I especially agree that REST is a set of principles. It's just that "is REST better than RPC" isn't the question at hand. Let's recap:


1. This post asks the question "RPC or REST in the cloud?"

2. Richard says it doesn't have to be one or the other - there's room for both.

3. Steve says "the success of the cloud WILL depend heavily on REST implementations of services running IN the cloud"

4. Richard responds, "I'm not advocating SOAP", "Both can exist, both are completely valid", and "My complaint is that someone nontechnical is going to read this and think you can only have one."


I think it's really important to stamp out these silly "which one is the absolute best" questions so we can move on to more useful dialogue. Again, I want to reiterate that I tend to agree with you about message-passing versus method-invocation in distributed apps.

but!

If I said, "the success of IoC/DI will depend heavily on spring", I think Uncle Bill might try to garbage collect me. Now re-consider the statement: "the success of the cloud WILL depend heavily on REST".

Re: Message-based vs. RPC by Steven Pena

In your analogy, REST would represented by the actual IoC/DI pattern... not Spring. Following your analogy further, I would state that the success of "separations of concerns" does depend on IoC, especially when compared to a pattern that wasn't even meant to address separation of concerns. REST is meant to address the need to represent the state (data) of a distributed system AND transfer of that information. To Bill's point, CORBA, SOAP, JAX-RPC, XML-RPC, RMI are all about protocols - it's not seeking to address the same need (apples and oranges). Those are merely focused on how to communicate with other systems.

Rephrasing of the original question:
------------------------------------
So yes, I agree the question is flawed to begin with as it demonstrates a lack of understanding of these two patterns. But that doesn't mean we can't still answer the implied question - "What are the best patterns for the cloud?", "What patterns will drive the success of the cloud?"

Like Richard, I think you are missing my whole point and choosing to pick on one statement and ignore all the supporting reasons. My point is two-fold...

Point 1:
------------------------------------
It's senseless to consider what Amazon is doing in order to determine an appropriate pattern for cloud-services. The success or suitability for an approach is going to be defined by the consumers of the services that sit on these clouds, not the cloud-service providers themselves. So we should be looking at the most popular services that sit in these clouds... Facebook and Twitter are excellent examples.

Point 2:
------------------------------------
My other point is entirely based on my belief that the Cloud's success and purpose is on surfacing data. If you disagree with that, then, yes, my points may seem unfounded. But supporting that belief is another discussion altogether. For now, I'll refer to the fact that the web proper is primarily focused on sharing data, the cloud supports the web...simple relationship there.

Popular services like Facebook and Twitter are largely popular due to their easy consumption and the data they expose. I can throw up one simple line of JS and now I've integrated a web site with these services. REST makes that largely possible. There are two parts to that - the technology in place and the ease of use. Web masters (notice the deliberate use of an old skool term) with a basic understanding of the web can understand how to put together a URL and HTML form. It's all about data - they don't need to understand an object model with both data and operations. Or introduce a framework for dealing with a dedicated protocol. Or implement a vendor specific library. REST provides prescription for a consistent way to querying and modify that data, one that is based on the same protocol they are already use to - HTTP.

Conclusion:
------------------------------------

I never said that REST is a uniform/best solution for all scenarios. But for the scenario of exposing data in a consistent way and for the most penetration (mobile devices, web pages, other web services...etc), REST is the best solution. I don't think that anyone would argue that the success of the cloud is largely dependent on the web. However, the web itself is the largest implementation of REST. That fact alone supports my original statement.

I agree with Bill that these message-based patterns are more easily understood. Looking at an architectural style that is easily understood, well suited for messaging and prescribes a resource-oriented interface is a much better architectural design and pattern.

Re: Message-based vs. RPC by Richard Clayton


I can throw up one simple line of JS and now I've integrated a web site with these services. REST makes that largely possible.

This is the point I've been making all along. How does REST enable us to consume the service with one line of JavaScript? Please show me that library! Somewhere, you have to make sense path/routing schema of the URL, as well as, the format in which the data comes back. If you are implying that I can access a known RESTful path via a JavaScript, the exact same is true for JSON-RPC.

REST may provide a more logical way for accessing "Resource-based" Services. But it is arguable as to whether it is "the best solution" as you say.

And your comment

However, the web itself is the largest implementation of REST. That fact alone supports my original statement.

Is only partially true. The HTTP specification defines the VERBs necessary to build a RESTful web service, but most websites do not orient themselves in this pattern. Most only support the GET and POST operations, and explicitly block PUT and DELETE. In fact, many REST implementations have had to find workarounds for this absence of the PUT and DELETE verb by "overloading" the POST verb.

Being RESTful entails more than just using HTTP. If that is your only criteria, than both SOAP over HTTP and RPC are RESTful. Fielding explicitly makes this point in his thesis: Architectural Styles and the Design of Network-based Software Architectures.

Re: Message-based vs. RPC by Steven Pena

I'm well aware of what Fielding wrote. I never said that HTTP was the only criteria, nor did I ever say that the web implemented every aspect of REST. You continue to cherry pick comments, pull them out of context and make counter points to them.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

21 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT