您正在查看 Apigee Edge 說明文件。
查看 Apigee X 說明文件。 資訊
身為服務供應商,您可以開發可供用戶端應用程式使用的 API。如要建立、設定及維護 API Proxy 和 API 產品,您可以使用 UI 或向 API 發出 HTTP 要求,藉此存取符合 REST 樣式的服務,如以下各節所述。
使用 Edge UI
Apigee Edge UI 是以瀏覽器為基礎的工具,可用來建立、設定及管理 API Proxy 和 API 產品。部分工作也只能透過 API 完成。
下表說明如何存取 Edge UI:
產品 | UI 名稱 | 存取網址 |
---|---|---|
Edge | Edge UI | 如要存取 Edge UI,請使用以下網址: https://apigee.com/edge 如需 Edge UI 的使用教學課程,請參閱建構第一個 API Proxy。 |
私有雲的邊緣 | 傳統 Edge UI | 如要存取 Edge for Private Cloud 的 Edge UI,請使用下列網址: http://ms-ip:9000 其中 ms-ip 是管理伺服器節點的 IP 位址或 DNS 名稱。 |
您可以使用 Edge UI:
- 編輯透過 Proxy 處理的程式碼和追蹤要求流程,藉此建立 API Proxy。
- 建立結合 Proxy 來觸及用戶端要求的 API 產品。
- 管理開發人員和開發人員應用程式。
- 設定測試和正式版環境。
- 實作 JavaScript 和 Node.js 應用程式。
下圖顯示 UI 中的 API Proxy 編輯器,可用來建立及設定 API Proxy:
使用 Edge API
您可以使用 Edge API 管理 API 資源。這些 API 也可以存取 UI 不會公開的低階功能。
API 端點通常會接收包含設定資訊的資料,並要求您傳送使用者名稱與密碼等驗證資訊,才能存取這些端點。遵循 REST 原則,您可以針對任何 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
的範例 API 要求,這是一種廣泛使用的 HTTP 用戶端。如需安裝 curl
,可以從 http://curl.haxx.se 下載。
呼叫 API 支援對回應使用 gzip 壓縮。如果您在 API 呼叫中設定 'Accept-Encoding: gzip, deflate'
,所有超過 1024 個位元組的回應都會以 gzip 格式傳回。
設定 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>
請注意,這個範例會透過 xmllint
讓回應使用 prettyprint
來顯示結果。
acurl
公用程式不支援 Accept
標頭。因此,您只能使用 acurl
取得 JSON 格式的回應。
如要在 JSON 回應中使用 prettyprint
,您可以使用 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 中嵌入或 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:「測試」和「正式版」。在公開發布 API 前,使用「測試」環境開發及測試 API。只有內部開發人員可以存取部署至測試環境的 API。將 API 部署至「正式版」環境,讓應用程式開發人員公開使用這些 API。
偵錯和測試
Apigee 提供追蹤記錄工具,可讓您對端對端要求與回應流程進行偵錯。追蹤記錄結果會顯示要求和回應標頭與酬載、政策執行程序、變數值,以及流程中可能發生的任何錯誤。
用於疑難排解的關鍵資料點:
- 時間戳記:使用時間戳記查看每個步驟的執行時間。比較時間戳記有助於您找出執行時間最長的政策,進而拖慢 API 呼叫的速度。
- 基本路徑:驗證基本路徑後,即可確保政策會將郵件轉送至正確的伺服器。
- 政策執行結果:這些結果可讓您瞭解訊息是否依預期修改,例如訊息從 XML 轉換為 JSON,或是否已快取訊息。
下圖顯示追蹤記錄結果:
每個追蹤工作階段都會細分為下列主要步驟:
- 從用戶端接收的原始要求:顯示來自用戶端應用程式要求的動詞和 URI 路徑、標頭、主體資料和查詢參數。
- 傳送至後端服務的要求:顯示 API Proxy 傳送至後端服務的要求訊息。
- 後端服務傳回的回應:顯示後端服務傳回的回應標頭和酬載。
- 最終傳送至用戶端的回應:執行回應流程後,傳回給提出要求用戶端應用程式的回應訊息。