開發工具

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

使用 Edge API

您可以使用 Edge API 管理 API 資源。 API 也提供對使用者介面未公開的低階功能的存取權。

API 端點通常會接收含有設定資訊的資料,且您必須傳遞驗證資訊 (例如使用者名稱和密碼),才能存取這些端點。遵循 RESTful 原則,您可以在任何 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 (廣泛使用的 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,或是訊息是否遭到快取。

下圖顯示追蹤結果:

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

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

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