A new, major version of AgileAssets API is created when a software modification breaks the functionality of an existing version. For example, switching from Jersey 1.xx to 2.xx would require the re-coding of objects that make AgileAssets entities. When changes to API functionality do not break existing functionality, then a new, major version is not required. For example, new entities or additional functions in already existing entities would not necessitate a new version.
The version number is part of the base URL from the entity path standpoint. In this way, AgileAssets does need to change every single path in the entity code to support a new version. Typically, a new version of API functionality would not be built from scratch and is instead based on the previous version. Therefore, objects that make up entities in the new version will be derived from classes that make up the old entities. To keep the code organized, all classes that make up entities are placed in a "resource" sub-folder, which contains only those classes that make up entities.
Everything directly related to AgileAssets APIs is stored in the "agileassetsinc.service.rest" package. Inside that package are classes that should not be affected by a new version. Classes that might change in a new version are stored under the "v1" folder for the first version of the APIs. When a second version is distributed, a "v2" folder is created — and so on for additional versions.
Inside the version folder, all classes that make up entities are stored in the "Resource" sub-package. Only these are used in entities.
To add a new version, the web.xml file must be changed. Each new version of APIs has its own RestServlet and end point. Shown below is an example of the lines in a web.xml file that must be changed to have version 1 put in place:
