API lifecycle management

This page describes the Google Cloud Endpoints API versioning features and provides best practices for versioning and staging your Cloud Endpoints API. The information on this page is applicable for APIs using the OpenAPI Specification. For APIs using Endpoints Frameworks for App Engine standard environment, see Handling API Versioning: Java or Handling API Versioning: Python.

We recommend that you follow the same basic principles that Google uses for API versioning and service staging:

  • Include the following in your OpenAPI configuration file before you deploy the initial version:

    • Set the version number in the info.version field. For example: 1.0.
    • Set the basePath field to the major version number. For example: /v1.
  • When you need to make a backwards-compatible change, such as adding a new method, increment the minor version number (1.2, 1.3, etc.) in the info.version field and redeploy. See Versioning an API for details.

  • When you need to make a change to an existing method that will break client code, make a copy of your OpenAPI configuration file, and make the following changes:

    • Increment the major version number (2.0, 3.0, etc.) in the info.version field.
    • Increment the major version number (/v2, /v3, etc.) in the basePath field.

Deploy both versions of your OpenAPI configuration files and redeploy the backend, which now has both versions of the method. See Versioning an API for details.

  • Implement all major API versions in a single backend. This recommendation:

    • Simplifies routing because requests to a specific version are based on the path, as in the example above.
    • Simplifies configuration and deployment. You use the same Cloud project and backend for all major versions of the API, and you deploy all versions of your API at the same time.
    • Keeps your costs down by avoiding running superfluous backends.
  • Stage your API in a separate Cloud project before you deploy to your production Cloud project. See Staging services for details.

The use of major and minor version numbers in Cloud Endpoints corresponds to the definitions in Semantic Versioning. Although Cloud Endpoints does not require that you increment the patch version number in your OpenAPI configuration file and deploy the configuration when you deploy a bug fix in your backend code, you can choose to do so if you like.

Cloud Endpoints API versioning features

The Extensible Server Proxy has the ability to manage multiple major versions of your API concurrently in a single Cloud project and backend as long as the APIs do not have overlapping paths. For example:

http://echo-api.endpoints.my-project.cloud.goog/v1/echo
http://echo-api.endpoints.my-project.cloud.goog/v2/echo

This allows your customers to pick which version they want to use and control when they migrate to the new version. The Extensible Server Proxy tags each request with the version number before routing the request to the applicable method in the backend. Because each request is tagged with a version number:

  • The graphs and logs in the Cloud Endpoints dashboard display requests from each major API version and the aggregate total across all versions. You can filter your view to a specific version. This gives you a clear idea of how much traffic each version is getting. The logs can even tell you which clients are using which version.

  • When you redeploy your API with a minor version number update, subsequent activity is labeled with the new version number in the graphs and logs in the Cloud Endpoints dashboard. This provides you with a labeled history of your deployments.

  • When you remove a version of an API, the graphs and logs continue to display data in the time range that the API was active.

API lifecycle example

This section describes a typical evolution of a service.

Version 1

You initially deploy version 1 of My Awesome Echo API service. The API is served from my-api.endpoints.my‐awesomeproject.cloud.goog/v1/echo. In the graphs and logs in your Cloud Endpoints dashboard, you see all traffic at 1.0.

Version 1.1

Your customers request a new feature, so you add a new method. In your OpenAPI configuration file, you add the new method and increment the info.version field to 1.1. You increment the minor version number because this change does not break client code. You deploy and test your change in a staging environment to ensure it works.

Next, you deploy the OpenAPI configuration and the API backend to the production environment. The API is still served from my-api.endpoints.my‐awesomeproject.cloud.goog/v1/echo, but now callers can make requests to the new method. Because you didn't change the interface to the old methods, your customers do not need to change and redeploy their clients; clients can continue to send requests to the old method the same as before.

In your Cloud Endpoints dashboard, you will see that the traffic being served is now at version 1.1. If you select an earlier time range to display, the Cloud Endpoints dashboard displays the previous version in the graphs and logs, which provides a labeled history of your deployments.

Version 2.0

Over time, you realize that you need to make a backwards-incompatible change to an existing method. Because it's important that you don't break your customers' client code, you decide to maintain two versions of the API. You leave the old method as it is, and implement the new version of the method. You create another OpenAPI configuration file for version 2.0, and configure the new version to be served from my-api.endpoints.my‐awesomeproject.cloud.goog/v2/echo. Your original OpenAPI configuration file still points to the old version of the method, while the new OpenAPI configuration file points to the new version of the method.

You deploy both version 1 and version 2 OpenAPI configuration files at the same time, and redeploy the backend, which now contains both versions of the method. (See Versioning an API for details.)

After you deploy, the Cloud Endpoints dashboard shows that there are two versions of your API being served, and you can see how much traffic each version is getting. Your v1 clients can continue to call /v1, but they can also call /v2 to use the new version of the method. How you handle versioning in your backend code depends on the API framework you are using. For an example using servlets, see Google Cloud Endpoints & Java with Multiple Versions sample.

Disabling version 1

In time, as your clients migrate and you see that all traffic to v1 has stopped, you can stop serving it. To remove version 1 of your API, deploy only the version 2 OpenAPI configuration file and redeploy the backend. You can now safely remove the code that implemented version 1 from your backend. The Endpoints dashboard will retain the historical data from version 1.x.

Staging services

As a best practice, we recommend that you stage updates to your Cloud Endpoints service so that you can test your service before it reaches your customers. We also recommend that you create a separate Cloud project for staging your service, so that it is isolated from production. For example, Google quotas are generally shared by resources within a project. Thus, if you put the staging service in the same project as the production service, an errant for loop, for example, could cause an outage in your production service.

We recommend that you devise a Cloud project name that clearly indicates it is for staging. A common naming strategy is to use the same name as your production Cloud project name, but with "-staging" at the end. You may also want to put "-prod" on production projects to make it clear that the project holds production services.

Service names on the Cloud Platform must be unique. Because you specify the name of the service in the OpenAPI configuration file, you need to either maintain separate API configuration files for the staging and production projects, or use one set of API configuration files and devise a process where you change the service name to match the name of the project that you are deploying to.

See also

Send feedback about...

Cloud Endpoints with OpenAPI