Question
AMERICAN EXPRESS
US
Last activity: 10 Jul 2017 18:28 EDT
How to create different versions of rest service in pega
We need to have different versions of rest service like v1 v2, what is the best way to do it in PEGA
Pegasystems Inc.
US
AMERICAN EXPRESS
US
Consumers should be able to use V1 and V2 at same time.
The requirement is we have a rest service which is used by multiple consumers and whenever there is a change in request / response structure or functionality we want to give the consumer some time before they had to upgrade to new service structure.
For example look at the below scenario where consumer has to do a change right away if there is no versioning
V1- Employee-Page
V2- Employee-Pagelist
Pegasystems Inc.
IN
In the request header can you add a new Parameter (V1/V2) and based on the value can you handle the required logic in your service activity.
AMERICAN EXPRESS
US
Consumers should be able to use V1 and V2 at same time.
The requirement is we have a rest service which is used by multiple consumers and whenever there is a change in request / response structure or functionality we want to give the consumer some time before they had to upgrade to new service structure.
For example look at the below scenario where consumer has to do a change right away if there is no versioning
Consumers should be able to use V1 and V2 at same time.
The requirement is we have a rest service which is used by multiple consumers and whenever there is a change in request / response structure or functionality we want to give the consumer some time before they had to upgrade to new service structure.
For example look at the below scenario where consumer has to do a change right away if there is no versioning
V1- Employee-Page
V2- Employee-Pagelist
Deutsche Bank
US
Any updates on this question? In Pega, the only option I see is to use version as a resource (ex. /svc_pkg/svc/method/1.0) but that is not ideal as you are still invoking a distinct version of Service-REST as well as underlying activities, which means maintaining if/else logic within the activities. It would probably be a feature request to extend the rest service definition to define a version, most likely at service package level (or a new rule, of service version, so that your URI can be /svc_pkg/1.0/svc/method)
Pegasystems Inc.
US
All the 'industry solutions" out there for this issue can be done in Pega as well. As you stated, there is the resource URI solution but other solutions include using a specialized "Accept:" header or custom request header - although both lead to firewall issues. The "EBay" solution is to use a parameter in the URI (E.g. "http://open.api.ebay.com/shopping?version=713" and PayPal does it as well).
Here is a great resource showing the myriad ways this is done all across the vast REST Service world - http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/.
I like any solution that allows the version to be left out and therefore will get the latest.
Hi Balaji,
Are end users supposed to be able to use v1 when v2 is available or will everyone be forced to use v2 once v2 is available?
Moreover could you explain your requirement a bit more details for our further understanding, so that it can helpful to understand your exact requirement.
Regards
Mahesh