Your question is pretty generic but I will try to give an answer and if it is too verbose or off the mark I will probably need more specific questions.
Firstly, the volume/capacity of any web service (as you've noted) is not so much a function of the type of web service it is (i.e. SOAP, REST, RPC, POX, etc) as much as the topology (architecture) on which the service is built (e.g. multi node, multi core, load balancer, highly-available, etc, etc.). A REST web service will not very much more volume than any other type of service if it is running on low powered physical or virtual hardware, just like any other type of web-based architecture.
That being said, RESTFul web services are gaining popularity over the more traditional style of web services (SOAP has been the most popular protocol in last 10-15 years), and one of the reasons for that is that they are much more lightweight than SOAP web services with a lot less redundancy. As such, they are quite well suited to high volume, low latency "micro service" API (a separate topic in its own right). The trade off is that they don't provide the rich metadata and "transport agnostic" messaging paradigm that is embedded in SOAP. Some will argue that in a http cloud-only world, that doesn't matter. I personally think it does, and REST web services are in many ways to SOAP what NoSQL database engines are to RDBMS - they are an alternative, not a replacement.
A side note, but it is important (to me, at least) to note here that REST (or "representational state transfer") is actually not a unique acronym for "web services", but it is in fact the term that describes the architectural style of the web; all interaction that uses TCP/IP (HTTP) is, technically, implementing the REST pattern (in other words, every website in existence, including this one, implements REST). However, the term has been hijacked and somewhat narrowed to describe a certain type of web service that is tightly coupled with HTTP , and typically uses JSON format for request/response message payloads. As such, some caution is advised when you hear "REST vs SOAP" - technically this is not comparing apples with apples and can be misleading.
RE your question on exact numbers, I cant give you that as it depends on far too many factors: size of payload, processing speed, business logic, etc. But it is certainly true to say that you can gain performance improvements over using SOAP/XML based messaging, by implementing a RESTFul style with JSON.