Pros and Cons of RESTful architecture [closed]

Question

The most common discussion I've seen regarding the pros and cons of REST tends to frame that discussion relative to SOAP. I have no experience in either. I am currently faced with a decision which my lack of experience is making hard for me to evaluate. I am beginning to develop an application that has several components - primarily an administrative aspect that allows the owner to administer several sites - and a public facing user interface that allows the user to interact with data held on the host. I need to evaluate the implications of allowing the latter part to be hosted anywhere and communicate with the former via a RESTful architecture - or demanding that both components reside on the same host. What are the key implications of developing RESTful architecture, particularly with regards to it's capacity in the following areas:

1: Security 2: Performance 3: Interface complexity

EDIT: Looking at some of the answers to this question - I should clarify. I'm not looking for a comparison to SOAP - rather an overview of REST applications vs applications where all components reside on one host. (thanks for those answers though!)

Answer 1

Given those areas, I can give a rough overview, but I can't draw your conclusions for you. There are two chief areas where the two protocols differ:

• Message format
• Service discovery

Message format is easiest to understand. The SOAP packaging for both requests and responses is fairly heavy weight. There's the SOAP envelope that contains both a header and a body section. The header can be used by several filters in the request chain to perform some sort of identification, authorization, etc. However, XML is expensive to parse, which yields a certain penalty to the scalability of your system. Just how much depends on the SOAP processing layer in your stack.

Service discovery is where you probably will have the most contention. REST by its very nature provides predictable end points, and the content of the request is a simple HTTP request. The benefit is that there is no additional overhead, and end users can pretty much guess how to do what they need once they understand the URL structure of your site. Of course, naive security conscious people will see that as a weakness. Afterall, with SOAP, you have to consume a WSDL to know what the endpoints are. Of course, with SOAP you were given the entire message format so you can make more targeted attacks.

Broken down by the categories you gave:

Security

Neither is inherently more secure than the other. Use good security principles:

• Encrypt communications
• Make sure you authenticate and authorize users before processing
• Good coding habits to avoid direct attacks
• And that's just the short list.

Remember obscurity != security.

Performance

Both raw performance and scalability will go to REST due to the request following simple HTTP protocols. Most SOAP stacks use SAX parsing (event based parsing) which greatly improves the scalability of SOAP stacks, but there is a measurable impact to the overhead. SOAP has the normal HTTP processing overhead in addition to the XML parsing overhead. REST just has the HTTP processing overhead.

Complexity

From the system's perspective, REST wins. There's fewer moving parts, a leaner request chain, etc. That means it's easier to make reliable.

From the programmer's perspective, SOAP can win if the IDE or framework you are using provides good support for it. Essentially, with REST the onus is on you to perform the preprocessing work (authentication/authorization/etc) while with SOAP much of that can be accomplished with a pluggable processing chain.

My Preference

I'm very comfortable with HTTP requests, and I know how the web works. As a result, the REST approach is more preferable for me. However, I do know that some of my clients are uncomfortable with that. They've read some industry article denouncing the security of REST vs. SOAP, etc. Bottom line is that neither approach guarantees security. It's on you to make sure the application is as secure as it needs to be. Obviously, a social web application doesn't demand (or desire) as much security as a bank or government system. Many SOAP stacks include processors that you can plug in to provide some semblance of security, but it is still your responsibility to search them out and put them in place.

Answer 2

1. Security: Use HTTPS. This applies to both.
2. Performance:. REST is less CPU expensive (less parsing, marshalling, unwrapping). Also, caching with REST is piece of cake.
3. Complexity: REST demands much less in terms of setup, it's just GET/POST after all. SOAP requires much more administration to maintain (wsdl etc), but is a bit easier if your IDE supports it.

I think SOAP is way too bloated when you can do the same thing with REST and some content/mime-types. Also, SOAP brings lots of overhead, due to its wrapping-of-wrappers nature and the fact that it is more general and not limited to HTTP. SOAP is tempting to use if your IDE supports it properly and you don't want to learn HTTP. But for me, REST is much easier to use and much more more web friendly.

Nowadays, there are very good REST APIs to use. If you're into Java, then Jax-RS is really cool. For some folks, this is like porn.

Answer 3

I think the biggest advantage of REST is to break from RPC architectures. REST exposes resources, not processes. That allows you to create a loosely bound system, where changes, improvements, even failures of one part have limited (negative) impact on other parts.

Unfortunately, a common misuse of REST is to expose your inner data structures (in the worst cases, it's a CRUD of your database, ugh). That makes it very hard to do it safely. The 'right' use is to expose high level objects that are relevant to the part of the system you're handling, and liberally return error status codes on any inconsistency.

Another often-overlooked part of REST is the idempotency of most verbs. Not only GET, but also PUT and DELETE should be exactly the same result if applied once or several times (you're free of returning a 404 if already deleted, or 'no change' if the client is PUTting the same). That leads to robust systems and less interdependency of exact interpretations of the semantics.

Answer 4

The WS-* standards really are mostly about running RPC over SOAP/HTTP. So, all the thinking that went into CORBA and J2EE and their predecessors have mostly moved to doing the same sort of things in XML. This means things like type declarations and service contracts, metadata exchange, declarative security etc. All that real "enterprisey" stuff. Its over-used even in the enterprise, frankly.

People building an internet web application such as yourself, would almost certainly be better off using a RESTful architecture. Almost any platform can consume it and do so simply and without worrying about which version of which spec you are using and a myriad of tool-specific type conversion quirks etc.

Answer 5

Only big advantage of SOAP over the current REST implementations is that SOAP is more easily tooled -- most RESTful clients require me to understand the interface and write a client of some sort. For SOAP, I just point wsdl.exe at it and it generates classes for me.