本頁面由 Cloud Translation API 翻譯而成。

建構簡單的 API Proxy
透過集合功能整理內容你可以依據偏好儲存及分類內容。

本頁適用於 Apigee 和 Apigee Hybrid。

查看 Apigee Edge 說明文件。

。

Apigee 可讓您快速將後端服務公開為 API。方法是建立 API Proxy，為您要公開的後端服務提供外觀。您只需要提供後端服務的網路位址，以及 Apigee 用來建立 API Proxy 並公開給開發人員的部分資訊。

API Proxy 會將後端服務實作與開發人員使用的 API 分離。這可讓開發人員不受後端服務日後的變更影響。當您更新後端服務時，開發人員可以繼續呼叫 API，不受這些變更影響。

本主題將說明各種 Proxy 類型和相關設定。如需建立 Proxy 的逐步操作說明，請參閱下列主題：

教學課程：建構第一個 API Proxy
建立 API Proxy

使用 UI 建立 API Proxy

如要建立 API Proxy，最簡單的方法就是使用「Create Proxy」精靈。

如要使用 Apigee UI 存取「Create Proxy」精靈，請執行下列步驟：

登入 Apigee UI。
在導覽列中，依序選取「Develop」>「API Proxies」。
按一下「建立新項目」。

「Create Proxy」精靈會顯示並引導您完成產生 API Proxy 及新增最低限度功能的步驟。

「建立 Proxy」精靈的第一頁，會提示您選取反向 Proxy、無目標或 Proxy 套件，以便自訂精靈流程。

在精靈的第一頁中，您可以從下列來源建立 API Proxy：

類型	說明
反向 Proxy (最常見)	將傳入要求轉送至現有 HTTP 後端服務的 API Proxy。可以是 JSON 或 XML API。請參閱本節稍後的「為 HTTP 服務建立反向 Proxy」一節。按一下「Use OpenAPI Spec」，即可根據有效的 OpenAPI 規格產生 Proxy。如要進一步瞭解這個選項，請參閱本節稍後的「使用 OpenAPI 規格產生 Proxy」。
未指定目標	沒有 API 後端 (「沒有目標」) 的 API Proxy。這與先前所述的為 HTTP 服務建立反向 Proxy類似，但在定義 API Proxy 詳細資料時，您不會指定現有的 API。按一下「Use OpenAPI Spec」，即可根據有效的 OpenAPI 規格產生 Proxy。如要進一步瞭解這個選項，請參閱本節稍後的「使用 OpenAPI 規格產生 Proxy」一節。
上傳 Proxy 套件	現有的 API proxy 套件 (例如 GitHub 上提供的 API proxy 範例)。請參閱「從 API Proxy 套件匯入 API Proxy」一文。

類型

說明

反向 Proxy (最常見)

將傳入要求轉送至現有 HTTP 後端服務的 API Proxy。可以是 JSON 或 XML API。請參閱本節稍後的「為 HTTP 服務建立反向 Proxy」一節。

按一下「Use OpenAPI Spec」，即可根據有效的 OpenAPI 規格產生 Proxy。如要進一步瞭解這個選項，請參閱本節稍後的「使用 OpenAPI 規格產生 Proxy」。

未指定目標

沒有 API 後端 (「沒有目標」) 的 API Proxy。這與先前所述的為 HTTP 服務建立反向 Proxy類似，但在定義 API Proxy 詳細資料時，您不會指定現有的 API。

按一下「Use OpenAPI Spec」，即可根據有效的 OpenAPI 規格產生 Proxy。如要進一步瞭解這個選項，請參閱本節稍後的「使用 OpenAPI 規格產生 Proxy」一節。

上傳 Proxy 套件

現有的 API proxy 套件 (例如 GitHub 上提供的 API proxy 範例)。請參閱「從 API Proxy 套件匯入 API Proxy」一文。

以下各節將討論各個 Proxy 類型的詳細資訊。

為 HTTP 服務建立反向 Proxy

Apigee 會根據下列資訊產生反向 Proxy：

後端服務的網址。
URI 路徑，可明確識別 API 代理程式將公開給消費者應用程式的 API。

後端服務網址通常代表貴機構擁有的服務啟用應用程式。也可以指向公開的 API。API 或服務可以由您控管 (例如，內部人力資源應用程式或雲端中的 Rails 應用程式)，也可以是第三方 API 或服務 (例如 Twitter 或 Instagram)。

您可以存取建立 Proxy 精靈，並選取Proxy 類型，取得下列Proxy 詳細資料：

欄位	說明
名稱	顯示的 API 名稱。指定英數字元、連字號 (-) 或底線 (_)。
基本路徑	API Proxy 的 `http://[host]` 或 `https://[host]` 位址後方顯示的 URI 片段。Apigee 會使用基礎路徑 URI 比對傳入的要求訊息，並將其轉送至適當的 API Proxy。注意：API 代理程式基本路徑預設為 `Name` 欄位指定的值，並轉換為全小寫。在基本路徑後方，是任何額外的資源網址。用戶端用來呼叫 API 代理的完整網址結構如下： `https://[host]/BASE_PATH/CONDITIONAL_FLOW_PATH` 注意：基本路徑必須是唯一的，您無法部署兩個使用相同基本路徑的 API 代理程式。如果您編輯已部署的 API Proxy，並將基本路徑設為與其他 API Proxy 的基本路徑相同的值，Apigee 會在您儲存時自動取消部署 API Proxy。您必須先編輯基底路徑，使其不重複，才能重新部署 API Proxy。在基礎路徑中使用萬用字元在 API Proxy 基礎路徑中使用一或多個 `//` 萬用字元，讓 API Proxy 能因應未來需求。舉例來說，`/team//members` 的基本路徑可讓用戶端呼叫 `https://[host]/team/blue/members` 和 `https://[host]/team/green/members`，而您不必建立新的 API Proxy 來支援新的團隊。請注意，系統不支援 `/**/`。
說明	(選用) API 說明。
目標 (現有 API)	這個 API Proxy 叫用的後端服務網址。

從 API Proxy 套件匯入 API Proxy

您通常會將 API 代理程式定義為 XML 檔案集合，以及任何其他支援檔案。將 API 代理程式定義為 Apigee 外部的一系列檔案，您就可以在來源管控系統中維護這些檔案，然後將這些檔案匯入 Apigee 進行測試和部署。

如要從 API Proxy 套件匯入 API Proxy，請執行下列步驟：

按照「使用 UI 建立 API Proxy」一文中所述，前往「Create Proxy」精靈。
按一下「上傳 Proxy 套件」。

在 Proxy 精靈的「Upload proxy bundle」頁面中，輸入下列資訊：

欄位	說明
ZIP 檔案組合	包含 API Proxy 設定的 ZIP 檔案。拖曳或點選檔案。
名稱	顯示的 API 名稱。預設為不含副檔名的 ZIP 檔案名稱。

點按「Next」。
在「Summary」頁面中選取部署環境 (如有需要)，然後按一下「Create and deploy」

系統會顯示確認訊息，證明您已成功建立新的 API Proxy。
按一下「編輯 Proxy」，即可顯示 API Proxy 的詳細資料頁面。

建立 gRPC API Proxy

除了 REST API Proxy 外，Apigee 目前也支援 gRPC API Proxy，但僅支援轉送功能。有了轉送支援，gRPC 酬載本身對 Apigee 來說是不可見的，且流量會從 gRPC 用戶端路由至目標設定中預先設定的 gRPC 目標伺服器。

目前，Apigee gRPC API Proxy 有以下功能：

支援單一 gRPC 要求。
無法使用會影響酬載的政策。
可用於與 GraphQL 或 REST 委派伺服器無關的 API 產品。API 產品專屬配額和其他作業設定會套用至產品中的所有 Proxy。
Apigee Hybrid 不支援。
使用兩個 gRPC 專屬的流程變數：request.grpc.rpc.name 和 request.grpc.service.name。
可使用以下 gRPC 專屬 Apigee Analytics 變數進行監控：x_apigee_grpc_rpc_name、x_apigee_grpc_service_name 和 x_apigee_grpc_status。
傳回 gRPC 狀態碼。

您也必須設定負載平衡器，以便支援 gRPC。請參閱「在應用程式中使用 gRPC」和「使用 gcloud CLI 指令建立 gRPC 路由」。

如要建立 gRPC API 代理程式，請先定義 gRPC 目標伺服器 (請參閱「建立 TargetServers」)，然後在建立新 Proxy 時指定該目標伺服器。

使用 gcloud CLI 指令建立 gRPC 的路由

本節將列出使用 gcloud CLI 建立 gRPC 代理程式路由的指令範例。操作說明包括設定負載平衡器、目標伺服器和 MIG。

本節並非建立路由的完整指南。這些範例可能不適用於所有用途。此外，這些操作說明假設您熟悉外部路由 (MIG) 和 Cloud 負載平衡器 gRPC 設定。

設定環境變數

這些環境變數會用於子區段中的指令。

PROJECT_ID=YOUR_PROJECT_ID
MIG_NAME=YOUR_MIG_NAME
VPC_NAME=default
VPC_SUBNET=default
REGION=REGION_NAME
APIGEE_ENDPOINT=ENDPOINT
CERTIFICATE_NAME=CERTIFICATE_NAME
DOMAIN_HOSTNAME=DOMAIN_HOSTNAME

使用新負載平衡器為 gRPC 代理程式建立路由的 gcloud CLI 指令範例

本節將列出使用 gcloud CLI 和新的負載平衡器建立 gRPC 代理伺服器的指令範例。操作說明包括設定負載平衡器、目標伺服器和 MIG。

建立執行個體範本

gcloud compute instance-templates create $MIG_NAME \
--project $PROJECT_ID \
--region $REGION \
--network $VPC_NAME \
--subnet $VPC_SUBNET \
--tags=https-server,apigee-mig-proxy,gke-apigee-proxy \
--machine-type e2-medium --image-family debian-12 \
--image-project debian-cloud --boot-disk-size 20GB \
--no-address \
--metadata ENDPOINT=$APIGEE_ENDPOINT,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh

建立代管執行個體群組

gcloud compute instance-groups managed create $MIG_NAME \
--project $PROJECT_ID --base-instance-name apigee-mig \
--size 2 --template $MIG_NAME --region $REGION

設定自動調度資源功能

gcloud compute instance-groups managed set-autoscaling $MIG_NAME \
--project $PROJECT_ID --region $REGION --max-num-replicas 50 \
--target-cpu-utilization 0.75 --cool-down-period 90

定義具名通訊埠

gcloud compute instance-groups managed set-named-ports $MIG_NAME \
--project $PROJECT_ID --region $REGION --named-ports https:443

為負載平衡器建立 Google 代管的 SSL 憑證和金鑰

gcloud compute ssl-certificates create $CERTIFICATE_NAME \
--domains=$DOMAIN_HOSTNAME \
--project $PROJECT_ID \
--global

驗證憑證是否已佈建

gcloud compute ssl-certificates describe $CERTIFICATE_NAME \
--global \
--format="get(name,managed.status, managed.Status)"

建立全球 Cloud Load Balancer (GCLB)

建立健康狀態檢查

gcloud compute health-checks create https hc-apigee-envoy-443 \
--project $PROJECT_ID --port 443 --global \
--request-path /healthz/ingress

建立 http1
的後端服務

gcloud compute backend-services create YOUR_BACKEND_1 \
--project $PROJECT_ID \
--protocol HTTPS \
--health-checks hc-apigee-envoy-443 \
--port-name https \
--timeout 302s \
--connection-draining-timeout 300s \
--global

建立 http2 的後端服務

gcloud compute backend-services create YOUR_BACKEND_2 \
--project $PROJECT_ID \
--protocol HTTP2 \
--health-checks hc-apigee-envoy-443 \
--port-name https \
--timeout 302s \
--connection-draining-timeout 300s \
--global

將 MIG 新增至後端服務。在本例中，我們會重複使用 MIG，但您也可以建立一組新的 MIG。

gcloud compute backend-services add-backend YOUR_BACKEND_1 \
--project $PROJECT_ID --instance-group $MIG_NAME \
--instance-group-region $REGION \
--balancing-mode UTILIZATION --max-utilization 0.8 --global

gcloud compute backend-services add-backend YOUR_BACKEND_2 \
--project $PROJECT_ID --instance-group $MIG_NAME \
--instance-group-region $REGION \
--balancing-mode UTILIZATION --max-utilization 0.8 --global

建立負載平衡網址對應。請先確認您是否已擁有網址對應項目。如果您有這類地圖，請務必依據下列規定修改該地圖，而非覆寫。

請使用此設定，在 /tmp/apigee-map.yaml 中建立 YAML 檔案或使用現有檔案。請注意，網址對應 http1 後端是預設值。

defaultService: projects/$PROJECT_ID/global/backendServices/YOUR_BACKEND_1
name: matcher1
routeRules:
- matchRules:
- headerMatches:
- headerName: Content-Type
prefixMatch: application/grpc
prefixMatch: /
priority: 100
routeAction:
weightedBackendServices:
- backendService: projects/$PROJECT_ID/global/backendServices/YOUR_BACKEND_2
weight: 100

驗證網址對應：

gcloud compute url-maps validate --source /tmp/apigee-map.yaml --project $PROJECT_ID

使用以標頭為基礎的轉送作業建立網址對應：

gcloud compute url-maps import apigee-http1-http2 \
--source /tmp/apigee-map.yaml  \
--global --project $PROJECT_ID

建立負載平衡目標 HTTPS Proxy

gcloud compute target-https-proxies create apigee-envoy-https-proxy \
--project $PROJECT_ID --url-map apigee-envoy-proxy-map \
--ssl-certificates $CERTIFICATE_NAME

為負載平衡器保留 IPV4 外部 IP 並建立防火牆規則

gcloud compute addresses create lb-ipv4-vip-1 \
--project $PROJECT_ID \
--network-tier=PREMIUM \
--ip-version=IPV4 \
--global

  gcloud compute addresses describe lb-ipv4-vip-1 \
--project $PROJECT_ID --format="get(address)" --global

  gcloud compute forwarding-rules create apigee-envoy-https-lb-rule \
--project $PROJECT_ID --address lb-ipv4-vip-1 --global \
--target-https-proxy apigee-envoy-https-proxy --ports 443

建立防火牆規則

gcloud compute firewall-rules create k8s-allow-lb-to-apigee-envoy \
--description "Allow incoming from GLB on TCP port 443 to Apigee Proxy" \
--project $PROJECT_ID --network $VPC_NAME --allow=tcp:443 \
--source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gke-apigee-proxy

建立現有負載平衡器 gRPC Proxy 路由的 gcloud CLI 指令範例

本節列出使用 gcloud CLI 和現有負載平衡器建立 gRPC 代理伺服器的指令範例。操作說明包括設定負載平衡器、目標伺服器和 MIG。

為 http2 建立另一個後端服務

# Create backend service for http2
    gcloud compute backend-services create YOUR_BACKEND_2 \
--project $PROJECT_ID \
--protocol HTTP2 \
--health-checks hc-apigee-envoy-443 \
--port-name https \
--timeout 302s \
--connection-draining-timeout 300s \
--global

將第二個後端服務附加至 MIG

gcloud compute backend-services add-backend YOUR_BACKEND_2 \
--project $PROJECT_ID --instance-group $MIG_NAME \
--instance-group-region $REGION \
--balancing-mode UTILIZATION --max-utilization 0.8 --global

列出現有 Apigee GCLB 的網址對應

gcloud compute url-maps list -project $PROJECT_ID

選取用於 Apigee 負載平衡的正確網址對應名稱

gcloud compute url-maps export APIGEE_URL_MAP_NAME -project $PROJECT_ID

建立負載平衡網址對應 YAML 檔案

如果您已有現有的網址對應，請將這項設定合併至該對應。否則，請在 /tmp/apigee-map.yaml 中使用此設定建立 YAML 檔案。

defaultService: projects/dg-runtime-test1/global/backendServices/YOUR_BACKEND_1
name: matcher1
routeRules:
- matchRules:
- headerMatches:
- headerName: Content-Type
prefixMatch: application/grpc
prefixMatch: /
priority: 100
routeAction:
weightedBackendServices:
- backendService: projects/dg-runtime-test1/global/backendServices/YOUR_BACKEND_2
weight: 100

套用新的 gRPC 轉送作業 YAML

gcloud compute url-maps import APIGEE_URL_MAP_NAME\
--source /tmp/apigee-map.yaml  \
--global -project $PROJECT_ID

增強安全性

在「建立 Proxy」精靈的「常見政策」頁面中，選取要新增的安全性授權類型。下表摘要列出可用的選項：

安全性授權	說明
API 金鑰	在您定義的 API Proxy 中加入簡易的 API 金鑰驗證機制。作為回應，API 平台會在 API 代理程式中新增 VerifyAPIKey 政策和 AssignMessage 政策。「VerifyAPIKey」政策會驗證要求應用程式提供的 API 金鑰。AssignMessage 政策會從轉送至後端伺服器的要求中，移除在 API 呼叫中做為查詢參數提供的 API 金鑰。
OAuth 2.0	為 API Proxy 新增 OAuth 2.0 驗證機制。Apigee 會自動將下列政策新增至 API Proxy：一項政策用於驗證存取權杖，另一項政策則會在將存取權杖轉送至後端服務前，先從訊息中移除這項權杖。如要瞭解如何取得存取權杖，請參閱 OAuth。
直接放行 (無授權)	無須授權。要求會傳送至後端，但不會在 Apigee 上進行任何安全性檢查。

新增 CORS 支援

跨源資源共享 (CORS) 是一種標準機制，可讓網路瀏覽器向其他網域提出直接要求。CORS 標準定義了一組 HTTP 標頭，供網路瀏覽器和伺服器用來實作跨網域通訊。

您可以透過下列任一方式新增 CORS 支援：

將 CORS 政策新增至 ProxyEndpoint 要求的 PreFlow
在「Create Proxy」精靈的「Common policies」頁面上選取「Add CORS headers」

如要進一步瞭解 CORS 支援，包括如何在 Proxy 中新增 CORS 預檢支援，請參閱「為 API Proxy 新增 CORS 支援」。

新增配額

配額可保護後端服務，避免在流量過高時發生問題。請參閱「配額」一文。(如果選取了「直通式授權」，則無法使用)。

使用 OpenAPI 規格產生 Proxy

本節將說明「使用 OpenAPI」選項，可從 OpenAPI 規格產生以下類型的 API Proxy：反向或無目標。

什麼是 OpenAPI 規範？

Open API Initiative 標誌「Open API Initiative (OAI) 專注於根據 Swagger 規範建立、改進及推廣供應商中立的 API 說明格式。」詳情請參閱 OpenAPI 計畫。

OpenAPI 規格使用標準格式說明 RESTful API。OpenAPI 規格採用 JSON 或 YAML 格式編寫，可供機器讀取，也便於人類閱讀和理解。規格說明會描述 API 元素，例如基本路徑、路徑和動詞、標頭、查詢參數、作業、內容類型、回應說明等。此外，OpenAPI 規格通常用於產生 API 說明文件。

以下是 OpenAPI 規格中的片段，說明 Apigee 的模擬目標服務 http://mocktarget.apigee.net。詳情請參閱 HelloWorld 範例的 OpenAPI 規格。

openapi: 3.0.0
info:
  description: OpenAPI Specification for the Apigee mock target service endpoint.
  version: 1.0.0
  title: Mock Target API
paths:
  /:
    get:
      summary: View personalized greeting
      operationId: View a personalized greeting
      description: View a personalized greeting for the specified or guest user.
      parameters:
        - name: user
          in: query
          description: Your user name.
          required: false
          schema:
            type: string
      responses:
        "200":
          description: Success
  /help:
    get:
      summary: Get help
      operationId: Get help
      description: View help information about available resources in HTML format.
      responses:
        "200":
          description: Success
...

您可以透過「Create Proxy」精靈匯入 OpenAPI 規格，然後使用該規格產生 API Proxy。產生 Proxy 後，您可以使用 Apigee UI 進一步開發 Proxy，例如新增政策、實作自訂程式碼等，就像任何 Apigee Proxy 一樣。

使用 OpenAPI 規格建立 API Proxy

使用 OpenAPI 規格建立 API Proxy。只要按幾下滑鼠，您就能取得 API 代理程式，其中包含自動產生的路徑、參數、條件流程和目標端點。接著，您可以新增 OAuth 安全性、頻率限制和快取等功能。

在「Create Proxy」精靈中，按一下「Use OpenAPI Spec」，然後按照精靈指示，使用 OpenAPI 規格建立反向或無目標的 Proxy。詳情請參閱「使用 OpenAPI 規格建立 API Proxy」。

建立 API Proxy 的新修訂版本

建立新的 API Proxy 修訂版本，如下所述。

如要建立 API Proxy 的新修訂版本，請執行下列步驟：

登入 Apigee UI。
在導覽列中，依序選取「Develop」>「API Proxies」。
在清單中按一下要複製的 API 代理程式。
按一下「開發」分頁標籤。
選取「儲存」按鈕，然後選取「儲存為新修訂版本」。

備份 API Proxy

您可以將現有的 API 代理程備份為 API 代理程套件中的 XML 檔案組合。匯出至套件後，您可以將 API 代理程式匯入新的代理程式，如本節先前所述的「從 API 代理程式套件匯入 API 代理程式」。詳情請參閱「下載 API Proxy」。

使用 API 建立 API Proxy

如要使用 API 建立 API Proxy，請參閱「建立 API Proxy」。

關於沒有目標 Proxy

如果您想在 Apigee 中處理要求，但不想將要求轉送至後端服務，則無目標 Proxy 在 Apigee 中就沒有用處。請務必瞭解何時適合採用這種做法。

常見用途

與 Apigee 管理的資料互動：如果您只需要與 Apigee 管理的資料互動，例如儲存在鍵/值對應 (KVM) 或 Apigee 快取中的資料，則無目標 Proxy 就很實用。舉例來說，您可以使用無指定目標的 Proxy，從 KVM 擷取資料，例如使用者工作階段資料或設定資料。在這種情況下，您不需要呼叫後端服務。只需在 Proxy 流程中設定 KeyValueMapOperations 政策即可。舉例來說，您可能會希望呼叫端要求清除快取。您可以叫用 InvalidateCache 政策來執行這項操作，而無需連線至目標。
使用模擬 API：您可以在後端實作完成前建立模擬 API，模擬 API 行為，讓前端開發作業能獨立進行。如要進一步瞭解如何建立模擬 API，請參閱 GitHub 上的 OpenAPI Mock API Proxy。
權杖管理：Apigee 可以發出 OAuthV2 權杖，通常會透過無目標 Proxy 執行。
測試政策行為：如果您想試用 Apigee 政策來測試其行為，無目標 Proxy 就很實用。