As we mentioned earlier in the API versioning section, services will always evolve with additional capabilities, enhancements, and defects fixes, however, now a service consumer can consume the latest version of our services without the need to keep changing their implementation or REST API endpoints. Also, the service consumer needs to be aware of the latest and evolving details of those service contracts.

The uniform contract pattern comes to the rescue to overcome these problems. The pattern suggests the following measures:

• Standardize the service contract and make it uniform across any service endpoints
• Abstract the service endpoints from individual services capabilities
• Follow the REST principles where the endpoints use only HTTP verbs, and express the underlying resources executable actions only with HTTP verbs

Please refer to the API versioning examples in the API versioning section as the implementation is already available and it has the flavor (please refer our investor service examples with GET, POST, DELETE, and so on) of the uniform contract.