Data format

SOAP exclusively uses XML (with complex rules for both the structure and content). REST doesn’t specify anything, even plain text is valid.

Transport protocol

SOAP defines operations on top of HTTP and SMTP, REST relies on HTTP only.

Service listing

SOAP provides WSDL to list what operations it provides (and how to access them), REST doesn’t define any.

Error handling

SOAP defines what to return when a request can’t be fulfilled, REST relies on HTTP status code only (which again, has no real standard. Some services return 200 with “error” field instead of returning 4XX when the request is invalid).

There are still other differences, but above should be enough to get an idea how one differs from the other by a simpler sentence: SOAP is rigid and strict (despite being highly extensible), while REST is dynamic and flexible (more like rule-free actually). Each has its own (dis)advantages, simply by looking above differences again.

When to use one over the other is more organizational and culture decision rather than technical. Who will develop and access the service? Which one the developers and accessors might be more comfortable to work with? etc.

However, talking about popularity, I haven’t found any new services written in SOAP. So far what I’ve seen are all REST, except for some legacy services entering maintenance mode. Even many of them deprecate the SOAP and provide REST version instead. I think the complexity of the rules and the use of complex XML (heavier data, slower transaction rate) are what drives SOAP to the cliff. The complexity of SOAP is not actually bad, in fact it can automate a lot of things, for instance by simply parsing WSDL client side wrapper can be magically done with 0 handcoding. But all those things are just tedious, even if you have all the tools to automate most of the processes.