Using Polycom APIs? Be version safe!

[Peter Lurie (luriep)]

As with most companies, Polycom works hard to continually improve our products.  With that comes changes in Polycom's software including in our APIs. (What is an API?  An API or Application Programming Interface can be thought of as an agreement provided by one piece of computer software to another.  If you ask me "X", then I will respond with "Y" in a specific format.) 

Polycom works to maintain both forwards and backwards compatability with our APIs, so a change in our software doesn't change the response back to your software-- we try not to break the "agreement". 

In order to write software that will work after upgrades, Polycom has released Best Practices to Prevent Versioning Issues in the Polycom RealPresence Platform API Guide  (see http://bit.ly/1shsRyN) 

For Example: Best Practices to Prevent Versioning Issues (from Page 25):

Developers using the API should use the following practices, to minimize software versioning related issues

and protect against unintentional agent upgrades:

• Use an XML parser that respects extension points in the schema, and ignores attributes that it does not understand at these points.
• Include the 'Content-Type' HTTP header in every request that includes an XML document.
• Include the 'Accept' HTTP header in every request that expects an XML document in response.
• Failure to include an 'Accept' header may result in a random, incompatible version being sent in a response. 

To determine whether a version is compatible, refer to the documentation for the API methods, which specifies what representations are possible as returned values.

• As part of the upgrade process for Polycom products, check the release notes for content types that are no longer supported. If there are any, make sure that they are not used in the client application

Polycom is committed to maintaining both forward and backward compatibility of the API where possible.  Typically, the API will support both the old and new content types when incompatible differences occur.

• API clients written to use an old version of the API may continue to do so, by specifying the old content type.
• API clients written to use the new version of the API may do so by specifying the new content type.

In some relatively rare cases, it may simply be impossible to support the old content type. In these cases, the release notes for the new version of the API will include a list of the content types that are no longer supported.

Want to learn more about what Polycom APIs can do?  Join the Polycom Developer Community or read the Polycom RealPresence Platform API Guide