REST API vs SOAP API?
up vote
2
down vote
favorite
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?
rest-api soap-api webservices rest soap
add a comment |
up vote
2
down vote
favorite
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?
rest-api soap-api webservices rest soap
Refer this: dzone.com/articles/difference-between-rest-and-soap-api
– Santanu Boral
3 hours ago
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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?
rest-api soap-api webservices rest soap
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?
rest-api soap-api webservices rest soap
rest-api soap-api webservices rest soap
asked 3 hours ago
User2529
319520
319520
Refer this: dzone.com/articles/difference-between-rest-and-soap-api
– Santanu Boral
3 hours ago
add a comment |
Refer this: dzone.com/articles/difference-between-rest-and-soap-api
– Santanu Boral
3 hours ago
Refer this: dzone.com/articles/difference-between-rest-and-soap-api
– Santanu Boral
3 hours ago
Refer this: dzone.com/articles/difference-between-rest-and-soap-api
– Santanu Boral
3 hours ago
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
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">
<soapenv:Header>
<urn:SessionHeader>
<urn:sessionId>[sessionId retrieved from the login() call]</urn:sessionId>
</urn:SessionHeader>
</soapenv:Header>
<soapenv:Body>
<urn:create>
<urn:sObjects xsi:type="urn1:Account">
<Name>Sample Inbound Account One</Name>
</urn:sObjects>
</urn:create>
</soapenv:Body>
</soapenv:Envelope>
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.
1
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.
– Daniel Ballinger
1 hour ago
@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
8 mins ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "459"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f243795%2frest-api-vs-soap-api%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
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">
<soapenv:Header>
<urn:SessionHeader>
<urn:sessionId>[sessionId retrieved from the login() call]</urn:sessionId>
</urn:SessionHeader>
</soapenv:Header>
<soapenv:Body>
<urn:create>
<urn:sObjects xsi:type="urn1:Account">
<Name>Sample Inbound Account One</Name>
</urn:sObjects>
</urn:create>
</soapenv:Body>
</soapenv:Envelope>
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.
1
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.
– Daniel Ballinger
1 hour ago
@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
8 mins ago
add a comment |
up vote
2
down vote
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">
<soapenv:Header>
<urn:SessionHeader>
<urn:sessionId>[sessionId retrieved from the login() call]</urn:sessionId>
</urn:SessionHeader>
</soapenv:Header>
<soapenv:Body>
<urn:create>
<urn:sObjects xsi:type="urn1:Account">
<Name>Sample Inbound Account One</Name>
</urn:sObjects>
</urn:create>
</soapenv:Body>
</soapenv:Envelope>
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.
1
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.
– Daniel Ballinger
1 hour ago
@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
8 mins ago
add a comment |
up vote
2
down vote
up vote
2
down vote
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">
<soapenv:Header>
<urn:SessionHeader>
<urn:sessionId>[sessionId retrieved from the login() call]</urn:sessionId>
</urn:SessionHeader>
</soapenv:Header>
<soapenv:Body>
<urn:create>
<urn:sObjects xsi:type="urn1:Account">
<Name>Sample Inbound Account One</Name>
</urn:sObjects>
</urn:create>
</soapenv:Body>
</soapenv:Envelope>
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.
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">
<soapenv:Header>
<urn:SessionHeader>
<urn:sessionId>[sessionId retrieved from the login() call]</urn:sessionId>
</urn:SessionHeader>
</soapenv:Header>
<soapenv:Body>
<urn:create>
<urn:sObjects xsi:type="urn1:Account">
<Name>Sample Inbound Account One</Name>
</urn:sObjects>
</urn:create>
</soapenv:Body>
</soapenv:Envelope>
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.
answered 2 hours ago
sfdcfox
245k11185418
245k11185418
1
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.
– Daniel Ballinger
1 hour ago
@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
8 mins ago
add a comment |
1
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.
– Daniel Ballinger
1 hour ago
@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
8 mins ago
1
1
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.
– Daniel Ballinger
1 hour ago
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.
– Daniel Ballinger
1 hour ago
@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
8 mins ago
@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
8 mins ago
add a comment |
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f243795%2frest-api-vs-soap-api%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Refer this: dzone.com/articles/difference-between-rest-and-soap-api
– Santanu Boral
3 hours ago