Versioning
Our API versioning strategy is based on URLs. A new version will be added at the root of the resource when there are breaking changing as shown below. Existing version will be updated when there are minor changes or bug fixes that are backward compatible.
https://eapi.prudential.com/{apigateway-base-path}/v1/{resource} https://eapi.prudential.com/{apigateway-base-path}/v2/{resource}
Breaking versus non-breaking changes
Breaking changes in API will be introduced in versioned releases (with a new major API version like v2 or v3). Non-breaking changes will be introduced to an existing API version. The following table provides examples of breaking and non-breaking changes.
| Breaking Changes | Major Version Release |
|---|---|
| Adding required fields in request/response | Yes |
| Rename a field, data type, or string constant | Yes |
| More restrictive change to field validations | Yes |
| Changing authentication or Authorization requirements | Yes |
| Non-Breaking Changes | Major Version Release |
|---|---|
| Adding optional fields in request/response | No |
| Adding optional request header | No |
| Adding new endpoints | No |
| Deprecation | No |
| Less restrictive change to field validations | No |
| Adding response header | No |
| Adding Enum values | No |