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!)

  • 3
    Suggest reopen. The question is common and clear with a reasonable scope of possible answers.
    – minghua
    Aug 29, 2014 at 6:34

5 Answers 5


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:


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.


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.


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.

  • 1
    +1 for a detailed answer. For a good Java JAX-RS implementation use RESTEasy. Combined with JAXB web services suddenly become trivial.
    – Gary
    Dec 3, 2010 at 13:46
  • 2
    "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." Actually, that is counter to REST's HATEOAS constraint ("Hypermedia as the Engine of Application State") if you are talking REST proper. There is a segment of REST advocates who will lynch you for implying that URL composition is an aspect of REST. I don't feel that strongly but many others do. Apr 16, 2011 at 6:52
  • 1
    And yet the predictable nature of the endpoints makes it easier to design and build an app. NOTE: frameworks supporting REST applications do have a consistent pattern of URLs, but they are not necessarily consistent from framework to framework. That regular pattern of URLs is simply a matter of programming construct and convenience. The URL patterns you see in Ruby on Rails apps are similar in the actions supported, but the names are different in ASP.NET MVC. Apr 16, 2011 at 11:55
  • Doing "design by URL" is a poor way of doing RESTful design that is encouraged by frameworks because it is easy for frameworks to do it that way. However, it usually breaks down badly one you get out of normal CRUD behaviour. Aug 2, 2011 at 11:26
  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.


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.

  • 1
    +1 for idempotency. I did see it once before but could not find it till now. Anybody know there is a tutorial about restful design in pdf mentions it?
    – minghua
    Aug 29, 2014 at 6:37

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.

  • Indeed: my experience of the WS-* standards has been that they are a glorious example of "standards" where every single implementation is different and incompatible. Keep it simple, imho, for public facing services, and only use SOAP for private communications between systems running on the same platform. Dec 3, 2010 at 20:40

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.

  • 1
    Have ever written a SOAP introspection tool yourself? It's an unpleasant experience that will switch you to REST.
    – pydanny
    Oct 19, 2012 at 14:05
  • 1
    No, but most platforms one looks at SOAP on have said introspection tools built. If I was looking at building one or doing rest I'd be doing the REST thing. Oct 19, 2012 at 17:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.