您目前查看的是 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info
身為服務供應商,您會開發供用戶端應用程式使用的 API。如要建立、設定及維護 API Proxy 和 API 產品,您可以使用 UI,也可以向 API 發出 HTTP 要求,存取符合 REST 樣式的服務,詳情請參閱下列章節。
使用 Edge UI
Apigee Edge 使用者介面是瀏覽器工具,可用於建立、設定及管理 API Proxy 和 API 產品。部分工作也只能使用 API 完成。
下表說明如何存取 Edge UI:
| 產品 | 使用者介面名稱 | 存取網址 |
|---|---|---|
| 邊緣 | Edge UI | 如要存取 Edge UI,請使用下列網址: https://apigee.com/edge 如需使用 Edge UI 的教學課程,請參閱「建構第一個 API Proxy」。 |
| 私有雲適用的 Edge | 傳統 Edge 使用者介面 | 如要存取 Edge for Private Cloud 的 Edge UI,請使用下列網址: http://ms-ip:9000 其中 ms-ip 是管理伺服器節點的 IP 位址或 DNS 名稱。 |
使用 Edge UI,您可以:
- 編輯程式碼並追蹤 Proxy 的要求流程,即可建立 API Proxy。
- 建立 API 產品,將 Proxy 組合在一起,以供用戶端要求使用。
- 管理開發人員和開發人員應用程式。
- 設定測試和實際工作環境。
- 實作 JavaScript 和 Node.js 應用程式。
下圖顯示使用者介面中的 API Proxy 編輯器,您可以使用這個編輯器建立及設定 API Proxy:

使用 Edge API
您可以使用 Edge API 管理 API 資源。 API 也提供對使用者介面未公開的低階功能的存取權。
API 端點通常會接收含有設定資訊的資料,且您必須傳遞驗證資訊 (例如使用者名稱和密碼),才能存取這些端點。遵循 RESTful 原則,您可以在任何 API 資源上呼叫 HTTP GET、POST、PUT 和 DELETE 方法。
如需 Apigee Edge API 的完整清單,請參閱「Apigee Edge API 參考資料」。
瞭解 Edge API 基礎路徑
您在 API 要求中使用的路徑會串連下列項目:
- 包含貴機構名稱的基本路徑。例如:
https://api.enterprise.apigee.com/v1/organizations/org_name - 指向您要存取的 Edge 資源的端點。
舉例來說,如果您的機構名稱是 apibuilders,則您對 API 進行的每次呼叫都會使用下列基本路徑:
https://api.enterprise.apigee.com/v1/organizations/apibuilders
如要擷取機構中的 API Proxy 清單,請對下列項目呼叫 GET:
https://api.enterprise.apigee.com/v1/organizations/apibuilders/apis
許多資源的範圍都以環境為準。系統預設提供兩個環境:測試和正式版。舉例來說,快取會依環境劃分範圍。每個環境預設都會包含名為「mycache」的共用快取。
您可以對快取資源呼叫 GET,列出快取,如下所示:
https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/test/caches https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/prod/caches
驗證存取權
呼叫 API 時,您必須向 API 伺服器驗證身分。你可以透過下列任一方式執行此操作:
此外,Apigee 建議您使用雙重驗證,詳情請參閱「為 Apigee 帳戶啟用雙重驗證」。
Edge API 限制
每個機構的 Edge API 呼叫頻率限制如下:
- 付費方案的機構每分鐘 10,000 次呼叫
- 試用機構每分鐘 600 次呼叫
HTTP 狀態碼 401 和 403 不會計入這項限制。如果呼叫次數超過這些限制,系統會傳回 429 Too Many Requests 狀態碼。
使用 Edge API 的訣竅
本節將說明一些技巧,讓您更輕鬆地使用 Edge API。
縮寫要求網址
建構 Edge API 的要求網址時,可以使用下列縮寫:
/e = /environments/o = /organizations/r = /revisions
如果使用縮寫,就必須保持一致。也就是說,路徑中的所有元素都要縮寫 (如上所述,並如下例所示),或都不縮寫。在同一路徑中同時使用完整和縮寫元素會導致錯誤。
例如:
THIS: https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/environments/prod/apis/helloworld/revisions/1/deployments CAN BE MUCH SHORTER: https://api.enterprise.apigee.com/v1/o/ahamilton-eval/e/prod/apis/helloworld/r/1/deployments
執行 curl 指令
使用 HTTP 用戶端對 API 提出要求。文件中的許多範例都使用 curl (廣泛使用的 HTTP 用戶端) 提供 API 要求範例。如需安裝 curl,請前往 http://curl.haxx.se 下載。
API 呼叫支援回應的 gzip 壓縮功能。如果您在 API 呼叫中設定 'Accept-Encoding: gzip, deflate',系統會以 gzip 格式傳回任何大於 1024 個位元組的回應。
設定 XML 和 JSON 要求與回應的格式
Edge API 預設會以 JSON 格式傳回資料。對於許多要求,您可以改為以 XML 格式取得回覆。如要這麼做,請將 Accept 要求標頭設為 application/xml,如下列範例所示:
curl -H "Authorization: Bearer `get_token`" \ -H "Accept: application/xml" \ https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \ | xmllint --format -
回覆應類似下方內容:
<List> <Item>SOAP-Message-Validation-1</Item> <Item>Spike-Arrest-1</Item> <Item>XML-to-JSON-1</Item> </List>
請注意,這個範例使用 prettyprint,透過 xmllint 管道傳送回應來顯示結果。
acurl 公用程式不支援 Accept 標頭。因此,您只能透過 acurl 取得 JSON 格式的回應。
如要將 prettyprint 用於 JSON 回應,可以使用 json.tool Python 程式庫:
curl https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \ -H "Accept: application/json" \ -H "Authorization: Bearer `get_token`" \ | python -m json.tool
以下是回應範例:
[ "SOAP-Message-Validation-1", "Spike-Arrest-1", "XML-to-JSON-1" ]
如果是 XML,可以使用 xmllint:
curl https://ahamilton-eval-test.apigee.net/getstarted -u email_address | xmllint --format -
以 XML 格式 POST 或 PUT 酬載時,請使用 Content-type HTTP 標頭:
acurl -H "Content-type:text/xml" -X POST -d \ '<XMLPayload> </XMLPayload> ' \ https://api.enterprise.apigee.com/v1/organizations/apifactory/apis -u email_address
部署環境
根據預設,每個使用 Apigee Edge 的機構至少有兩個環境,可用於開發、測試及部署 API:「test」和「prod」。在 API 公開發布前,請先使用「測試」環境開發及測試 API。只有內部開發人員可以存取部署至測試環境的 API。將 API 部署到「prod」環境,即可公開提供給應用程式開發人員使用。
偵錯和測試
Apigee 提供追蹤工具,可讓您偵錯端對端要求和回應流程。追蹤結果會顯示要求和回應標頭與酬載、政策執行、變數值,以及流程中可能發生的任何錯誤。
用於疑難排解的關鍵資料點:
- 時間戳記:透過時間戳記瞭解每個步驟的執行時間。 比較時間戳記有助於找出執行時間最長的政策,這些政策會導致 API 呼叫速度變慢。
- 基本路徑:驗證基本路徑可確保政策將郵件轉送至正確的伺服器。
- 政策執行結果:這些結果可讓您查看訊息是否如預期遭到變更,例如訊息是否從 XML 轉換為 JSON,或是訊息是否遭到快取。
下圖顯示追蹤結果:

每個追蹤工作階段都會細分成下列主要步驟:
- 從用戶端收到的原始要求:顯示用戶端應用程式的要求動詞和 URI 路徑、標頭、主體資料和查詢參數。
- 傳送至後端服務的要求:顯示 API Proxy 傳送至後端服務的要求訊息。
- 後端服務傳回的回應:顯示後端服務傳回的回應標頭和酬載。
- 傳送給用戶端的最終回應:回應流程執行完畢後,傳回給提出要求的用戶端應用程式的回應訊息。