2

We've been using v33.0 to download all the data from our Salesforce account. Today, we found out that one of the SObject got deprecated in v34.0 because the API threw HTTP 400 error and we wasted some time debugging. So I'm wondering is there some quick way to keep track of the API changes on the dataset only without going through the whole N pages of release notes for each release please?

1

If you choose to run describes, you could find the differences in the fields that are enumerated. I would suggest using SOAP or REST getDescribe() calls as opposed to the Metadata API, which can be slightly trickier to use.

However, to get to the heart of the matter, you really shouldn't be updating to the latest version of the API "just because." The reason for API versions is so that your app will continue to work despite new releases. In other words, the API is designed to provide an app backwards compatibility.

You should only upgrade your API version after you understand the implications of doing so, and this means reading the release notes and/or examining the results of describe calls. After a release of a particular API, support for that API is guaranteed for at least three years, and is typically longer than that.

You don't need to upgrade your API version unless salesforce.com tells you to (e.g. they are deprecating an API permanently), or you need to use the new features of a newer version. In this case, you'd want to read the release notes in order to make sure that your code will be compatible with the new version.

There is no guarantee that a later API version will be compatible with an older API version, which is why versions were introduced to begin with. Some API's guarantee backwards compatibility, which causes bloat and fixes bad designs in place permanently.

By merely emulating different API versions, they can fix broken features and add new features without affecting existing clients and integrations, while allowing new clients and integrations to use an updated version of the API.

Most integrations should not attempt to automatically use the latest version of the API. Each integration should be built to work with a certain API version, and should be maintained in that version until a decision is made to update the entire code base to a newer version, including regression testing. Generic integrations, like a Data Loader app, can probably safely update to a new version, but anything more specialized than that should avoid doing so.

Having multiple API versions available also lets you maintain a stable, older API version integration while building an integration that supports a newer API version in testing environments until you're confident that you can release the integration to production.

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.