11

I have a requirement to Integrate Salesforce with SAP Business Objects(BOJ) to retrieve some data in Real time and display using VF page. I will send Account Id from Salesforce and retrieve Billing information from BOJ(Just Query, no insert or updates). I want to know whether SOAP API or Apex REST API is better for this implementation. In SF SOAP documentation, I read below point. Does it mean, SOAP API require lot of maintenance overhead in future? We don't want to go for External Objects as we don't have 'OData' type paid feature enabled.

SOAP API End-of-Life

Salesforce is committed to supporting each SOAP API version for a minimum of three years from the date of first release. In order to improve the quality and performance of SOAP API, versions that are more than three years old may cease to be supported. When a SOAP API version is scheduled to be unsupported, an advance end-of-life notice will be given at least one year before support for SOAP API version is ended. Salesforce will directly notify customers using SOAP API versions scheduled for end of life.

12

This statement is simply stating that a particular version of the API is only guaranteed to be supported for three years. In other words, salesforce guarantees version compatibility for three years. Salesforce currently supports version 20 (the Winter 11 API) through 39 (the Spring 17 API).

If you build an application today, using version 39, it is guaranteed to be supported until at least version 48 (Spring 20 API). Salesforce's current API support supports any applications written or last updated in the past six years.

This isn't exclusive to the SOAP API; the REST API, Metadata API, Streaming API, and so on all have similar notices. This means that some periodic maintenance may be required for any application that uses any API.

You can view the currently supported API versions here.

  • So in order to retain the functionality, do we have to do any changes in our implementation whenever a particular version turns obsolete? This is the first web service I am going to implement in SFDC, so wanted to make sure I choose best approach. – Amulya Feb 15 '17 at 18:56
  • 1
    @Amulya First, you'll be notified by email at least a year in advance before the version goes obsolete; this gives you time to update the application before it becomes inoperable. In many cases, simply regenerating the stub from the latest WSDL and recompiling is sufficient, but you'll want unit tests in place to make sure that nothing breaks. Most applications need little to no actual fixing other than upgrading the stub classes. – sfdcfox Feb 15 '17 at 19:00
  • Got it, thank you. Now specifically in my scenario, are there any key points to consider while choosing SOAP or REST. Since we only want to fetch data from External application, do you suggest anyone in particular? Or if there is any blog I can refer which is easier to start with? – Amulya Feb 15 '17 at 19:16
  • 1
    @Amulya They're basically the same as each other; the main limitation is what your programming tools support. For example, in Java, it is often easier to use SOAP, while in JavaScript, it is often easier to use REST. Use whichever is the most comfortable in your desired language. Keep in mind that a version encompasses all of the APIs: REST, SOAP, Bulk, Streaming, Metadata, and Tooling. That means it doesn't matter if you choose REST or SOAP, they'll both be supported for the same amount of time. – sfdcfox Feb 15 '17 at 19:21
5

The SOAP API is not going anywhere and will almost certainly never be deprecated. You missed a key word in that documentation: version. A specific API Version of the SOAP API may eventually be deprecated, but not the API itself.

  • Got it. I read in many places that it's good to go for REST API's as it's latest and easy to maintain, I blindly assumed SOAP is getting obsolete!! – Amulya Feb 15 '17 at 18:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.