Salesforce SOAP vs REST

Question

I have been building a console app the uses the Saleforce SOAP API, and now need to use the Salesforce API in a web app.

Am I correct to assume that SOAP is better suited for a non web-based app, and REST is better for a web app?

If I where to create a wrapper that would be used in either reporting from local apps, or posting to salesforce from our websites, should I expose both the REST and SOAP api's, depending on what the app is? Or should I just stick to using one? What are deciding factors I should look at if I just need to pick one?

Postaxial

Answer 1

The other answers contain some good general info, some salesforce specific things to take into account are

1) You can directly bulk update data in the SOAP API, but you'll need to use the Async Bulk API to do that from REST.

2) The soap API contains a few things not available in the REST API, most notably describeLayout, queryAll, getDeleted & getUpdated

3) the REST API contains a few things not available in the SOAP API, including the API for chatter, and access to the recently accessed records lists.

4) the REST API can access binary data (files, attachments, content, etc) without the overhead of base64 encoding/decoding.

So, depending on exactly what your app is trying to do may push you one way or the other.

Excruciate

On point #2, it's no longer true that the REST API doesn't contain those endpoints. E.g., you can getDeleted: salesforce.com/us/developer/docs/api_rest/Content/… – Leupold

Answer 2

I believe it ends up being personal preference if you're consuming it by a .NET application, regardless of whether it's a web app or not.

Personally, I would go with SOAP as .NET has a lot of built in functionality to consume a SOAP service, it builds all the method prototypes for you and will make development faster than you handcrafting REST requests yourself. .NET will take care of the marshalling of SOAP.

As for building a wrapper, you have to consider your target audience, if your target audience is other .NET application developers, then exposing your own WCF service might be a decent option, WCF also has endpoints for either SOAP or REST.

Gastronomy

Answer 3

IMHO, if you are developing the solution from .NET as your question indicates, SOAP is the way to go. REST services are beneficial because they lack the bulk and tool set requirements that surround SOAP and are nice for the bootstrap developer without access to heavy investment tools like .NET. I agree with the other comments that REST more closely mirrors the underlying HTTP methodology, and is easier to read and parse explicitly, but that isn't really something you have to concern yourself with from within a tool like VS and .NET.

Additionally, since you have existing console apps that may be brought into the communication mix at some point, it might be good to have the WCF flexibility to be transport agnostic and not tied to HTTP as you would be with REST.

So I really don't think you are in a position to take advantage of the REST advantages or be impacted by the shortcomings of SOAP, so it makes sense to go with the heavily standardized option that fits best into your existing tool set.

Beaird

Answer 4

The decision to use REST or SOAP when both are available is usually related to:

1. The tools and language you're using for your application
2. Your familiarity with either style
3. The performance needs of your application (JSON payloads are smaller than XML payloads)

If the 'local' apps are calling the services from the server side, then all else being equal, you can at least generate C# code directly from the WSDL and that makes using the SOAP API simpler (no hand coding).

If the web application needs to call the API directly from the client side (browser), then use REST and work with JSON. This will be far simpler. You wouldn't be able to reuse the same wrapper regardless, so no problem using two different APIs other than the time it takes to learn them.

If the web app usage of the API is on the server (not client) side, then definitely target just a single API. WSDL if you want to auto-generate the code to call it, REST otherwise for simplicity and efficiency.

Bewley

Answer 5

IMO, SOAP was a standard created as a contract type messaging architect, I.e. When passing messages just use this "contract." It was generic enough that it doesn't embrace any particular technology.

REST is a actual methodology that embraces HTTP, it is a way of utilizing GET, POST, PUT and DELETE to it's max potential.

I wouldn't assume one is better then the other, what it really boils down to is using the right tool for the job. I wouldn't make a distinction between web-based app and non web-based. Because SOAP or REST can be beneficial to both.

Here are a few questions I would get answered first:
1) Who is my target client. Microsoft Workshop Client, Java, PHP type.
2) What types of (Lack of a better term.) "Endpoints" do I want to expose to my Api. (JSON, XML, Ajax, POX or all of the above.)
3) What will my clients be going with this API? Do they already have clients that are based on SOAP. If so, SOAP is the way to go.
4) REST will makes you think about your URL design and thus allowing a client to "mashup" data to build what they need. So if you think that's something you want. REST is the way to go.
5) REST makes use of the "GET" in HTTP, this allows a client to cache results. "Conditional GET is what it's called. It allows them to cache a big object, ask the server via just a header (small) if the last update matches what is cached, if so. don't bother with a full object GET, what is cached is the latest version. This can be done in SOAP, but out of the box, REST is better for this.

Anyway, hopefully that gives you the better data, so you can make the better decision. And if all else fails you can just do both. But then you'll have to deal with trying to get two types of services (different methodologies) and one codebase for both. (can be tricky, but not that difficult.)

Personally. I would pick one, then if you ever need the other, burn that bridge and pay the technical debt for it.

Addia

Answer 6

Late to this party, but just a quick note:

The Salesforce API isn't completely RESTful: I would call it REST-ish. It has SQL-like queries in URLs for some of its REST interface, that sort of thing.

Malvinamalvino

Answer 7

SOAP API:

What is it for? Integrating your organization’s data with other applications using SOAP.

When to use it? You have pre-existing middleware services that need to work with WSDLs and XML data.

Protocol SOAP/WSDL Data format XML Communication Synchronous

REST API:

What is it for? Accessing objects in your organization using REST. When to use it? You want to leverage the REST architecture to integrate with your organization. No WSDL requirement. Well-suited for browser-based applications, mobile apps, and highly-interactive social applications. Protocol REST Data format JSON, XML Communication Synchronous

Masterly