One of the differences between REST and SOAP is that REST is lighter than SOAP. What does it mean when they say REST APIs are lighter than SOAP APIs? How is JSON lighter than XML?


1 Answer 1


When a developer talks about something's "weight" (heavier or lighter), we're referring to the resources it consumes. SOAP requires substantially more memory and bandwidth than a JSON string of the same representation. To make matters worse, SOAP is an extension of XML, adding even more bloat to the entire process. To give you a simple comparison, consider these two functionally identical requests:

SOAP (Create Call)

POST /services/Soap/u/44.0
Host: mydomain.my.salesforce.com
Content-Type: text/xml; charset=utf-8
Content-Length: nnn
SOAPAction: ""

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:enterprise.soap.sforce.com" xmlns:urn1="urn:sobject.enterprise.soap.sforce.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <urn:sessionId>[sessionId retrieved from the login() call]</urn:sessionId>
      <urn:sObjects xsi:type="urn1:Account">
        <Name>Sample Inbound Account One</Name>

REST (Equivalent to above)

POST /services/data/44.0/sobjects/Account
Host: mydomain.my.salesforce.com
Authorization: Bearer [sessionId retrieved from a login call]
Content-Type: application/json; charset=utf-8
Content-Length: nnn

{ "Name": "Sample Inbound Account One" }

And this is with just one field. The more fields and records used, the more SOAP will fall behind in efficiency compared to REST. Most methods that you can use in SOAP can also be used in REST, and vice versa. The heavy weight of SOAP can make requests take longer in areas where bandwidth is limited, and may cause low-memory devices to fail from a lack of memory sooner. Overall, when resources are at a premium, you want to use REST.

The reason why you'd use SOAP at all is because you're using some application or language that only "understands" SOAP, or makes REST obnoxiously hard to use. For example, in some languages, you import a "WSDL" and calling the service literally only takes a few lines of code, while the same thing in REST requires importing a JSON parser, an HTTPS library, jump through some encoding hoops, etc. In other languages, the opposite is true: there is no SOAP support (but SOAP is really just a special case of normal HTTP calls), so SOAP is harder to implement and error prone, while REST would be naturally supported.

  • 2
    It's true. The JSON based REST payload will be smaller than the equivalent SOAP based call. If you actually notice the difference in practice will depend on the nature of the calls. As you say, in a bandwidth/memory constrained environment every little optimization you can make would help. Or if you were sending serious volumes of data it would be worth trying to keep things minimal. However, for many day-to-day server to server applications you'd be hard pressed to measure the difference. In which case go with what the tooling supports. Dec 17, 2018 at 7:38
  • 2
    @DanielBallinger I'm not saying "use REST for everything", just "if you get an equal choice, prefer REST." Equal meaning both have equal tooling, similar dev times, and support the necessary business logic. If one finds themselves in this situation, REST should be preferred, because it's better to have better performance and not need it, than to not have it when you do. In most cases, the API of choice will already be chosen anyways, either by tooling, language, difficulty of implementation, etc.
    – sfdcfox
    Dec 17, 2018 at 8:58
  • Our (almost)real time backup solution showed a significant difference in backup records/min in REST vs SOAP in testing. SOAP was actually faster, much faster. Is there an article on Salesforce that could potentially explain this ? I always assumed REST would be faster if not equal to SOAP.
    – Nagen Sahu
    Jul 20, 2023 at 12:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .