Rest.li 2.0 introduces a new backwards incompatible URI format, as well as removes several APIs that have been marked as deprecated for quite some time. You can find details about these changes on our user guide as well as our protocol documentation. This page documents the steps needed to upgrade from a 1.x release to a 2.x release.
Having issues with any of the steps listed below? Please create an issue and someone from the Rest.li team will help you.
Take these steps to make your source code compatible with Rest.li 2.x:
-Xlint:deprecation
flag when using javac
.com.linkedin.restli.client.BatchRequest#getIdObjects
. If you look at the Javadoc for this method we have instructions on what to use instead.For the most part the protocol changes are taken care off under the hood by Rest.li. As an application developer, you don’t have to worry about the Rest.li 2.0 protocol changes.
However, if you are hard coding URLs, HTTP request/response bodies, or HTTP request/response headers in your code you will have to update these to the Rest.li 2.0 protocol format. Details of the protocol can be found on this page.
The basic rules for upgrading and deploying your clients and servers is as follows:
If you have a complicated Rest.li call graph involving multiple Rest.li services, start the upgrade and deployment process at the leaf nodes of the graph (i.e. the Rest.li services that don’t call other Rest.li services) and work your way backwards.