Find out how smart businesses are turning COVID-19 from a challenge into an opportunity

Tell me more
Jul
15
2021 Posted by James Gill

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:

 

DB2 REST API Improved Versioning Control

As you’ll see from the following runs (from Windows PowerShell using Invoke-WebRequest), the default is the first one defined – V1.0.0

 
DB2 Native REST API Improved Versioning Control

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:
 

DB2 REST Services Fault

 
Now when we drive the default version of the service:

 
DB2 REST API Result Set Output

 

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

Your email address will not be published. Required fields are marked *

« Previous |
Have a Question?

Get in touch with our expert team and see how we can help with your IT project, call us on +44(0) 870 2411 550 or use our contact form…