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.
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.