DB2 for z/OS Native REST API – Improved Versioning Control
Introduction
One of the challenges with the DB2 for z/OS REST versioning implementation was that the default version – the version that gets run when a client doesn’t express a version ID in the request – is the first version defined. Which means that you either have to manage the version driven from your application (not always simple when your microservice is used extensively by many different applications), or you had to hack the DSNSERVICES catalog table as outlined in the previous blog on versioning here. This method was not approved of by IBM, but was the only means of changing the default version at the time of writing (2018).
Improved Control
Following a prompt from the labs, we looked in to PH34544 (UI75327), which allows us to change the default version of a REST service.
To begin with, we will define a service that just returns its own (hard coded) version number. To create two different versions, we used:
And version 2.0.0 will use:
As you’ll see from the following runs (from Windows PowerShell using Invoke-WebRequest), the default is the first one defined – V1.0.0
And we can drive the individual versions to confirm:
V1.0.0:
V2.0.0
So, how do we change the default version? Previously the only option was to hack the SYSIBM.DSNSERVICE catalog table – which was not IBMs intention. However, with the release of PH34544 (UI75327) we can now change the default by REBINDing and using the new RESTSERVICEDEFAULT(YES) option, like this:
The result is confirmed in the messages:
Now when we drive the default version of the service:
Caveat Emptor – Let the Buyer Beware
As noted in the APAR text and the original post on this subject, there is no checking for compatibility – i.e. If V1 of your service takes two integer parms and V3 takes 5, you will need to manage the interface compatibility challenges. No warnings will be issued by this process, so good design is still the important
Access all of James Gill’s Native REST API blogs here.
Leave a Reply