版本資訊

本頁面包含 Cloud Endpoints 的版本資訊,說明本服務的功能及異動項目。如需資訊瞭解可擴充服務 Proxy (ESP) 的更新內容,請參閱 GitHub 的 Endpoints 執行階段版本資訊

2018 年 9 月

Cloud Endpoints Frameworks v1 已關閉

適用於 App Engine 標準環境的 Cloud Endpoints Frameworks v1,已於 2017 年 8 月 2 日停用。2018 年 9 月 13 日已關閉該服務,並已移除文件。

Endpoints Frameworks Python:變更預設記錄層級

Endpoints Frameworks Python 之中新增變更預設記錄層級的功能。詳情請參閱在適合 Python 的 Endpoints Framework 中記錄

2018 年 8 月

Cloud Endpoints 入口網站更新

Cloud Endpoints 入口網站目前已正式推出。此版本包含下列新功能及強化功能:

透過 API 同步處理自訂說明文件

現在可利用 API 將自訂說明文件同步至您的入口網站。詳情請參閱以下與 API 實作相關的說明文件:

在自訂說明文件加入圖片

您可以新增圖片到自訂內容 Git 存放區,並在 Markdown 檔案中參照這些圖片。詳情請參閱以下與 API 實作相關的說明文件:

SmartDocs API 參考說明文件簡介

在入口網站顯示 API 參考說明文件,並提供試用這個 API 面板的元件稱為:「SmartDocs API 參考說明文件」。SmartDocs 原本是為 Cloud Endpoints 入口網站開發,目前也於 Apigee 的整合開發人員入口網站提供使用。

Cloud Endpoints Frameworks v1 即將關閉

適用於 App Engine 標準環境的 Cloud Endpoints Frameworks v1,已於 2017 年 8 月 2 日停用。該服務的預定關閉日期為 2018 年 9 月 3 日,並將移除說明文件。為了避免中斷運作,您必須遷移 v1 應用程式。如需更多詳細資訊,瞭解如何將應用程式遷移至 Endpoints Frameworks v2,請參閱下列資料:

停用 ESP 之中的追蹤記錄取樣功能

ESP 會針對傳送至您 API 的要求進行小量採樣,並將追蹤記錄傳送至 Stackdriver Trace。ESP 1.19.0 版新增 ESP 啟動選項,可停用追蹤記錄取樣功能。此選項目前已提供使用,可部署於 App Engine 彈性環境。

詳情請參閱以下 API 實作說明文件之中的「追蹤 API」:

Endpoints Frameworks 用於 App Engine 標準環境,並未使用 ESP 進行 API 管理,也不會傳送追蹤資料至 Stackdriver Trace。

2018 年 7 月

Cloud Endpoints 入口網站的全新角色與權限

Google Cloud Identity and Access Management (Cloud IAM) 角色、Endpoints 入口網站管理員及多項新的 Cloud IAM 權限目前已提供使用。新角色及權限可讓您控制專案成員對 Cloud Endpoints 入口網站的存取程度。

詳情請參閱以下 API 實作說明文件之中的「Cloud Endpoints 入口網站權限」:

2018 年 6 月

程式庫及外掛程式更新

  • 適用於 Python 程式庫的 Endpoints Frameworks 4.4.0 版,已新增強化功能,可由 endpoints 程式庫匯入 message_typesmessagesremote 類別,而不是由 protorpc 程式庫匯入。在您定義 API 的檔案中,我們建議您變更匯入陳述式,將以下項目:

    import endpoints
    from protorpc import message_types
    from protorpc import messages
    from protorpc import remote
    

    變更為:

    from endpoints import message_types
    from endpoints import messages
    from endpoints import remote
    

    此項匯入陳述式的選用變更,可簡化 Endpoints Frameworks 程式庫的程式碼。

  • 適用於 Java 程式庫的 Endpoints Frameworks 2.1.0 版,目前會驗證具有必要參數的要求。如果要求之中忽略了必要參數,Endpoints Frameworks 將傳回狀態碼 HTTP 400 Bad Request。

Cloud Endpoints 入口網站推出測試版

您可利用 Cloud Endpoints 入口網站建立開發人員入口網站;Cloud Endpoints API 使用者可存取此網站閱讀說明文件,並與 API 互動。

詳情請參閱以下 API 實作說明文件之中的「Cloud Endpoints 入口網站總覽」:

2018 年 3 月

ESP 代管發佈選項

ESP --rollout_strategy=managed 選項目前已提供使用,適用於以 OpenAPI 或 gRPC 描述的 API。此選項會將 ESP 設定為使用最新部署服務設定。指定此選項時,在您部署新的服務設定後的一分鐘內,ESP 便會偵測到變更並自動開始使用它。建議您指定此選項而非讓 ESP 使用特定的設定 ID。

此選項未於 Endpoints Frameworks 提供使用。

雖然代管發佈選項已自 1.7.0 版之後於 ESP 提供使用,gcloud 指令列工具現在已更新,讓該選項能在 App Engine 彈性環境提供使用。目前此選項僅於 gcloud 指令列工具測試版提供使用。您將選項新增至 app.yaml 之後,需要使用 gcloud beta app deploy 指令以部署 API 及 ESP。

如需部署 ESP 及此新選項的相關資訊,請參閱以下 API 實作說明文件:

程式庫及外掛程式更新

  • 適用於 Python 程式庫的 Endpoints Frameworks 3.0.0 版,可能含有破壞性變更。
    • 目前可以部署含多個 API 的單一服務,不過在使用此項功能時,有一些 API 名稱的額外限制。更多詳細資料請參閱部署及測試 API
    • 之前的 API 版本字串,會依照原樣嵌入至路徑中,例如 API echo 版本 v1 的路徑為 /echo/v1。對於不相容於 SemVer 標準的 API 版本字串,仍是採用這種方式處理。若字串與 SemVer 標準相容,部署 API 時就會擷取主要版本編號並嵌入至路徑中。例如名為 echo 的 API,在版本為 2.1.0 的情況下,路徑就是 /echo/v2。如果將您的 echo API 更新為 2.2.0 版,並部署具回溯相容性的變更,路徑仍然為 /echo/v2。這使您可以在進行具回溯相容性的變更時更新 API 版本編號,而不會破壞用戶端的現有路徑。但如果您將 echo API 更新為 3.0.0 版 (因為您正在部署破壞性變更),路徑將會變更為 /echo/v3

2018 年 1 月

Endpoints 資訊主頁目前能夠比較設定檔與之前版本。在排解特定部署的問題時,查看設定檔中的差異可能會有所幫助。詳情請參閱以下與 API 實作相關的說明文件:

程式庫及外掛程式更新

  • 適用於 Python 程式庫的 Endpoints Frameworks 2.5.0

2017 年 12 月

Endpoints DNS

Endpoints DNS 功能目前已正式推出。您可設定 Endpoints 以註冊網址,用於呼叫 API。對於並未使用 App Engine 的使用者,這是呼叫 API 的便利方式,無需使用 IP 位址或註冊網域名稱。API 可利用網址呼叫,例如:

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

詳情請參閱以下 API 實作說明文件的「在 cloud.goog 網域設定 DNS」頁面:

Endpoints DNS 搭配 SSL

目前提供範例,顯示如何針對設定使用 cloud.goog 網域的 API 啟用 SSL。詳情請參閱以下與 API 實作相關的說明文件:

2017 年 11 月

篩選特定的消費者專案

針對特定消費者專案篩選指標的功能,目前於 Endpoints 資訊主頁以 Alpha 測試版功能的方式提供使用。詳情請參閱以下與 API 實作相關的說明文件:

程式庫及外掛程式更新

  • 適用於 Python 程式庫的 Endpoints Frameworks 2.4.5

  • Endpoints Framework Gradle 外掛程式 1.0.3

  • Endpoints Framework Maven 外掛程式 1.0.3

2017 年 10 月

推出配額測試版

您可設定配額以指定用量上限,避免您的 API 要求數量過多。若要瞭解更多配額相關資訊,請參閱以下 API 實作說明文件的「關於配額」頁面:

gcloud 端點及 gcloud 服務

Cloud SDK 指令群組 gcloud 端點gcloud 服務目前已正式推出。gcloud 端點及 gcloud 服務指令群組,是用於取代已停用的 gcloud 服務管理。

程式庫更新

  • Python 程式庫適用的 Endpoints Frameworks 2.4.1 版已提供使用。

  • Java 程式庫適用的 Endpoints Frameworks 2.0.9 版已提供使用。

2017 年 8 月

API 指標目前於 Stackdriver 發佈。您可監控要求比率、延遲時間及其他項目。如需瞭解設定警示相關資訊,請參閱以下 API 實作說明文件的「監控 API」頁面:

您可在 Stackdriver 指標清單找到完整指標清單。

2017 年 7 月

您現在可透過身分與存取權管理 API,以程式輔助方式授予存取權至個別 API。詳情請參閱 API 實作的「API 存取權總覽」頁面。

2017 年 5 月

如果沒有提供 API 金鑰,Endpoints 目前會將呼叫歸類至生產端專案,並報告後端使用的通訊協定 (gRPC、HTTP)。

2017 年 4 月

Endpoints 現在可選擇註冊網址,用於呼叫 API。對於並未使用 App Engine 的使用者,這是呼叫 API 的便利方式,無需使用 IP 位址。API 可利用網址呼叫,例如:

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

詳情請參閱 OpenAPI 設定頁面gRPC 設定頁面

2017 年 2 月

API 部署歷史記錄目前於 Google Cloud Console 提供,可讓您檢視 API 設定部署的歷史記錄。不過,這項功能目前還在測試階段。

API 部署歷史記錄可顯示是誰更新特定設定、設定更新時間,及其設定 ID 為何。這有助於尋找 API 的設定 ID,以及設定變更屬性。

如欲檢視新畫面,請前往 Cloud Console 的 Endpoints UI 區段,並按下「部署歷史記錄」分頁標籤。

2017 年 1 月

我們正在變更可擴充服務 Proxy (ESP) 的行為,根據預設將拒絕跨源資源共享 (CORS) 要求;若您仰賴 CORS 要求,就必須變更設定,明確允許 CORS 要求,並在 2017 年 1 月 2 日前重新部署。

背景及目前行為

在使用 CORS 標準的情況下,瀏覽器會插入額外的 OPTIONS 要求至伺服器,判定是否有權限執行跨源要求。目前 ESP 一律接受 OPTIONS 要求,代表目前的 ESP 一律接受透過 CORS 的跨源要求。

近期異動內容

ESP 將允許服務生產端指定是否允許跨源流量。根據預設,ESP 將拒絕所有 OPTIONS 要求,以「封鎖」跨源要求。如果您要讓 API 允許跨源要求,就需要將下列程式碼片段新增至 OpenAPI 設定。

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

請配合以下事項

請按照下方相關分頁的操作說明執行。

App Engine Flex

於 2017 年 1 月 2 日推出 ESP 1.0 後,所有彈性環境 API 部署將採用新版 ESP,並將自動根據預設不允許 CORS 要求。App Engine 應用程式每 7 日會自動重新部署,所以在推出 ESP 1.0 之後 7 日期間,應用程式將以最新版重新啟動,並將獲得自動保護,避免非計劃中的跨源共享。

若您使用彈性環境,並希望繼續允許 CORS 要求,就必須將前述的「x-google-endpoints」程式碼片段新增至 API 設定 (又稱為 OpenAPI 規格或 Swagger 檔案)。若您仰賴 CORS,我們建議您儘快新增程式碼片段,並使用下列指令重新部署服務,避免服務中斷。之後新版 ESP 推出時,您就不會看到變更行為。

gcloud app deploy app.yaml

Kubernetes Engine

我們預計在 2017 年 1 月 2 日發佈 ESP 1.0 版時推出此項變更。

若您目前使用 CORS 啟用跨源流量至 API,在 1 月 2 日後將 ESP 升級為 1.0 版時,就需要變更 API 設定 (又稱 OpenAPI 規格或 Swagger 檔案)。請將以上的「x-google-endpoints」程式碼片段新增至 API 的 OpenAPI 設定,然後使用下列指令重新部署 API 設定。

gcloud service-management deploy openapi.yaml

請注意,以上步驟會將新服務設定推送至服務管理員。請記下新的 SERVICE_CONFIG_ID,在下個步驟將會用到。

現在您需要重新部署服務。您可利用下列指令,將 ESP-DEPLOYMENT 更換為您服務的部署名稱。

kubectl edit deployment/ESP-DEPLOYMENT

此項指令可開啟 GKE 設定 YAML,並讓您更新部署。請確保將 ESP 版本變更為 1.0,將 SERVICE_CONFIG_ID 更新為新的 SERVICE_CONFIG_ID,然後儲存部署。

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

我們預計在 2017 年 1 月 2 日發佈 ESP 1.0 版時推出此項變更。

若您目前使用 CORS 啟用跨源流量至 API,將 ESP 升級為 1.0 版時就需要變更 API 設定 (又稱 OpenAPI 規格或 Swagger 檔案)。請將以上的「x-google-endpoints」程式碼片段新增至 API 的 OpenAPI 設定,然後使用下列指令重新部署 API 設定。

gcloud service-management deploy openapi.yaml

請注意,以上步驟會將新服務設定推送至服務管理員。請記下新的 SERVICE_CONFIG_ID,在下個步驟將會用到。

在重新部署服務之前,需要以下列指令更新 VM 的中繼資料項目:

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

之後您需要將安全殼層 (SSH) 加入至 VM,並執行下列指令以重新啟動 ESP。

sudo /etc/init.d/nginx restart

或者若您使用 start_esp.py 指令碼啟動 ESP (而非使用 init.d 指令碼),就可以停止 ESP,並以更新後的 SERVICE_CONFIG_ID 重新執行 start_esp.py 指令。

Compute Engine + Docker

我們預計在 2017 年 1 月 2 日發佈 ESP 1.0 版時推出此項變更。

若您目前使用 CORS 啟用跨源流量至 API,將 ESP 升級為 1.0 版時就需要變更 API 設定 (也就是 OpenAPI 規格或 Swagger 檔案)。請將以上的 x-google-endpoints 程式碼片段新增至 API 的 OpenAPI 設定,然後使用下列指令重新部署 API 設定。

gcloud service-management deploy openapi.yaml

這樣會將新服務設定推送至 Google Service Management。該指令將為您的 API 傳回新的 SERVICE_CONFIG_ID;請將其記下,在下個步驟中將會用到。

接下來請重新部署服務。首先請利用下列指令停止及移除現有的 ESP 執行個體 (例如「esp」)。您可利用 sudo docker ps 指令找出現有 ESP 執行個體。

sudo docker stop esp
sudo docker rm esp

接下來請執行下列指令,重新部署 ESP。請務必使用新的 SERVICE_CONFIG_ID 用於 -v 選項。

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
本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Cloud Endpoints
需要協助嗎?請前往我們的支援網頁