開發工具

您正在查看 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 UI 的 API Proxy 編輯器中選取的「開發」分頁。

使用 Edge API

您可以使用 Edge API 管理 API 資源。這些 API 也可以存取 UI 不會公開的低階功能。

API 端點通常會接收包含設定資訊的資料,並要求您傳送使用者名稱與密碼等驗證資訊,才能存取這些端點。遵循 REST 原則,您可以針對任何 API 資源呼叫 HTTP GETPOSTPUTDELETE 方法。

如需 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 狀態碼 401403 不會計入這個限制。超過這些限制的呼叫會傳回 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,或是否已快取訊息。

下圖顯示追蹤記錄結果:

顯示在 Edge UI 的 API Proxy 編輯器中選取的「Trace」分頁。

每個追蹤工作階段都會細分為下列主要步驟:

  • 從用戶端接收的原始要求:顯示來自用戶端應用程式要求的動詞和 URI 路徑、標頭、主體資料和查詢參數。
  • 傳送至後端服務的要求:顯示 API Proxy 傳送至後端服務的要求訊息。
  • 後端服務傳回的回應:顯示後端服務傳回的回應標頭和酬載。
  • 最終傳送至用戶端的回應:執行回應流程後,傳回給提出要求用戶端應用程式的回應訊息。