Release notes

This page contains release notes for features and updates to Google Cloud Endpoints. For information about updates to the Extensible Service Proxy (ESP), see the Endpoints Runtime Release Notes on GitHub.

March 2018

ESP managed rollout option

The ESP --rollout_strategy=managed option is now available for APIs described with OpenAPI or gRPC. This option configures ESP to use the latest deployed service configuration. When you specify this option, within a minute after you deploy a new service configuration, ESP detects the change and automatically begins using it. We recommend that you specify this option instead of a specific configuration ID for ESP to use.

This option is not available in Endpoints Frameworks.

Although the managed rollout option has been available in ESP since version 1.7.0, the gcloud command line tool has now been updated to make the option available on the App Engine flexible environment. Currently, the option is available only in the beta version of the gcloud command line tool. After you add the option to your app.yaml, you will need to use the gcloud beta app deploy command to deploy your API and ESP.

For information on deploying ESP with this new option, see the documentation for your API implementation:

Library and Plugin Updates

  • The Endpoints Frameworks for Python library, version 3.0.0, contains potentially breaking changes.
    • It is now possible to deploy a single service comprising multiple APIs. However, there are additional restrictions on API names when using this functionality. See Deploying and Testing an API for more details.
    • Previously, API version strings were embedded in the path as-is. For example, an API echo with version v1 would have a path like /echo/v1. This continues to be the case for API version strings that are not compatible with the SemVer standard. If the string is compatible with the SemVer standard, the major version number will be extracted and embedded in the path when you deploy your API. So, for example, an API called echo with version 2.1.0 would have a path like /echo/v2. If you update the echo API to version 2.2.0 and deploy a backwards-compatible change, the path remains /echo/v2. This allows you to update the API version number when you make a backwards-compatible change without breaking existing paths for your clients. But if you update the echo API to version 3.0.0 (because you are deploying a breaking change), the path is changed to /echo/v3.

January 2018

The Endpoints dashboard now provides the ability to compare a configuration file with the previous version. Viewing the differences in your configuration files might be helpful when troubleshooting a problem with a particular deployment. To learn more, see the documentation for your API implementation:

Library and Plugin Updates

  • The Endpoints Frameworks for Python library, version 2.5.0

December 2017

Endpoints DNS

The Endpoints DNS feature is now generally available. You can configure Endpoints to register a URL that you can use to call your APIs. For people not using App Engine, this provides a convenient way to call APIs without using your IP address or registering a domain name. The API can be called with a URL such as:

echo-api.endpoints.my-project-id.cloud.goog

To learn more, see the "Configuring DNS on the cloud.goog domain" page in the documentation for your API implementation:

Endpoints DNS with SSL

A sample that shows how to enable SSL for APIs configured to use the cloud.goog domain is now available. To learn more, see the documentation for your API implementation:

November 2017

Filter for a specific consumer project

The ability to filter metrics for a specific consumer project is now available as an Alpha feature in the Endpoints dashboard. To learn more, see the documentation for your API implementation:

Library and Plugin Updates

  • The Endpoints Frameworks for Python library, version 2.4.5

  • The Endpoints Framework Gradle plugin, version 1.0.3

  • The Endpoints Framework Maven plugin, version 1.0.3

October 2017

Beta Launch of Quotas

Quotas let you specify usage limits to protect your API from an excessive number of requests. To learn more about quotas, see the "About Quotas" page in the documentation for your API implementation:

gcloud endpoints and gcloud services

The Cloud SDK command groups gcloud endpoints and gcloud services are now generally available. The gcloud endpoints and gcloud services command groups are a replacement for gcloud service-management, which is deprecated.

Library Updates

  • The Endpoints Frameworks for Python library, version 2.4.1 is available.

  • The Endpoints Frameworks for Java libraries, version 2.0.9 are available.

August 2017

API metrics are now published in Stackdriver. You can monitor request rates, latencies and much more. For information on setting up alerts, see the "Monitoring your API" page in the documentation for your API implementation:

You will find a complete list of metrics in the Stackdriver metrics list.

July 2017

You can now programmatically grant access to individual APIs via the IAM API. See the "API Access Overview" page for your API implementation to find details.

May 2017

Endpoints now attributes calls to the Producer project if no API key is provided and reports the protocol used by the backend (gRPC, HTTP).

April 2017

Endpoints can now optionally register a URL that you can use to call your APIs. For people not using App Engine, this gives a convenient way to call APIs without using your IP address. The API can be called with a URL such as

echo-api.endpoints.my-project-id.cloud.goog

For details, see the OpenAPI configuration page or the gRPC configuration page.

February 2017

API Deployment History is now available in the Google Cloud Console, allowing you to view the history of API config deployments. This functionality is currently in Beta.

The API deployment history shows you who uploaded a particular configuration, when it was uploaded, and what its configuration ID is. This is helpful for finding configuration IDs and attribution of configuration changes for your API.

To see the new screen, navigate to your API in the Endpoints UI section of the Cloud Console and click on the Deployment History tab.

January 2017

We are changing the behavior of the Extensible Service Proxy (ESP) to deny cross-origin resource sharing (CORS) requests by default; if you rely on CORS requests, you must change your configuration to explicitly allow them and redeploy by January 2, 2017.

Background & Current Behavior

With the CORS standard, a browser inserts an extra OPTIONS request to the server to determine whether it has permission to perform a cross-origin request. Currently the ESP always accepts OPTIONS requests. This means that currently ESP always allows cross-origin requests through CORS.

Upcoming Changes

ESP will allow service producers to specify whether or not to allow cross-origin traffic. By default, ESP will block cross-origin requests by rejecting all OPTIONS requests. If you want to allow cross-origin requests for your API, you will need to add the following snippet to the service's OpenAPI configuration.

...
"host": "echo-api.endpoints.YOUR_PROJECT_ID.cloud.goog",
"x-google-endpoints": [
  {
    "name": "echo-api.endpoints.YOUR_PROJECT_ID.cloud.goog",
    "allowCors": "true"
  }
],
...

What You Need to Do

Follow the instructions in the appropriate tab below.

App Engine Flex

After ESP 1.0 is released on January 2, 2017, all Flexible Environment API deployments will feature the new version of ESP and will automatically disallow CORS requests by default. App Engine applications are automatically redeployed every 7 days, so sometime in the 7 days following the release of ESP 1.0, your app will be restarted with the latest version and will automatically be protected from unintended cross origin sharing.

If you are using Flexible Environments and would like to continue to allow CORS requests, you must add the "x-google-endpoints" snippet above to your API configuration (aka OpenAPI specification aka Swagger file). If you are relying on CORS, we recommend that you add the snippet as soon as possible and redeploy your service using the following command to avoid service interruption. Then you will not see changed behavior when the new version of ESP rolls out.

gcloud app deploy app.yaml

Kubernetes Engine

We plan to introduce this change in the version 1.0 release of ESP on January 2, 2017.

If you are currently using CORS to enable cross-origin traffic to your API, you will need to make changes to your API configuration (aka OpenAPI specification aka Swagger file) when you upgrade ESP to version 1.0 after January 2. Add the above "x-google-endpoints" snippets to the OpenAPI config for your API, and re-deploy your API configuration using the following command.

gcloud service-management deploy openapi.yaml

Note that the above step pushed your new service config to the service manager. Note the new SERVICE_CONFIG_ID, you will need it in the next step.

Now you need to redeploy your service. You can use the following command, replacing ESP-DEPLOYMENT with the deployment name for your service.

kubectl edit deployment/ESP-DEPLOYMENT

This command opens up your Kubernetes Engine configuration YAML and let you update the deployment. Make sure to change your version of ESP to 1.0 and update the SERVICE_CONFIG_ID to the new SERVICE_CONFIG_ID, and save the deployment.

containers:
    - name: esp
      image: gcr.io/endpoints-release/endpoints-runtime:1.0
      args: [
        "--http_port", "8080",
        "--backend", "localhost:8081",
        "--service", "SERVICE_NAME",
        "--version", "SERVICE_CONFIG_ID",
      ]

Compute Engine

We plan to introduce this change in the ESP version 1.0 release on January 2, 2017.

If you are currently using CORS to enable cross-origin traffic to your API, you will need to make changes to your API configuration (aka OpenAPI specification aka Swagger file) when you upgrade ESP to version 1.0. Add the above "x-google-endpoints" snippets to the OpenAPI config for your API, and re-deploy your API configuration using the following command.

gcloud service-management deploy openapi.yaml

Note that the above step pushed your new service config to the service manager. Note the new SERVICE_CONFIG_ID, you will need it in the next step.

Before redeploying your service, you need to update the metadata entries on the VM with the following command:

gcloud compute instances add-metadata --metadata=endpoints-service-name=SERVICE_NAME,endpoints-service-config-id=SERVICE_CONFIG_ID

Then you need to SSH to the VM and run the following command to restart ESP.

sudo /etc/init.d/nginx restart

Alternatively, if you use the start_esp.py script to start ESP (instead of the init.d script), you can stop ESP and re-run the start_esp.py command with the updated SERVICE_CONFIG_ID.

Compute Engine + Docker

We plan to introduce this change in the version 1.0 release of ESP on January 2, 2017.

If you are currently using CORS to enable cross-origin traffic to your API, you will need to make changes to your API configuration (known as the OpenAPI specification or Swagger file) when you upgrade ESP to version 1.0. Add the above x-google-endpoints snippets to the OpenAPI config for your API, and re-deploy your API configuration using the following command.

gcloud service-management deploy openapi.yaml

This pushes your new service config to Google Service Management. That command will return a new SERVICE_CONFIG_ID for your API. Note it down because you will need it in the next step.

Next, redeploy your service. First stop and remove the current ESP instance (e.g., "esp") using the following commands. You can use sudo docker ps command to find out the current ESP instance.

sudo docker stop esp
sudo docker rm esp

Then, run the following command to redeploy ESP. Make sure to use the new SERVICE_CONFIG_ID for -v option.

sudo docker run --name=esp -d -p 80:8080 --link=echo:echo gcr.io/endpoints-release/endpoints-runtime:1.0 -s [SERVICE_NAME] -v [SERVICE_CONFIG_ID] -a echo:8081

Send feedback about...

Cloud Endpoints