錯誤原因

請求的 HTTP Schema 不正確。

不同 API 支持的 HTTP Schama 不同，API 提供者可以自行設置，支持僅 HTTP 訪問、僅 HTTPS 訪問，或者同時支持 HTTP 和 HTTPS。

API unsupport the channel：HTTP，API 只允許 HTTPS 訪問，而發起 API 請求時卻使用了 HTTP，則會得到此提示。

API unsupport the channel：HTTPS，API 只允許 HTTP 訪問，而 API 請求卻使用的是HTTPS，則會得到此提示。

解決方案

API unsupport the channel：HTTP，更換為 HTTPS，發起 API 調用。

API unsupport the channel：HTTPS，更換為 HTTP，發起 API 調用。

錯誤原因

客戶端與服務端計算的簽名不匹配導致的問題。

解決方案

當簽名不匹配時網關會通過 HTTP Response Header 中的 X-Ca-Error-Message 返回服務端參與簽名計算的 StringToSign。

StringToSign是用戶請求前需要拼接的一個用于計算簽名的字符串，在文檔：【使用摘要簽名認證方式調用API】查看詳細說明。

客戶端只需打印出本地自己拼接的 StringToSign 進行對比，找出哪里不同，針對性的解決，如果使用的官方提供的調用 Demo，可以到簽名計算的工具類中找出計算簽名前的 StringToSign 打印出來即可進行對比。

因為 HTTP Response Header 中不允許出現換行符，因此返回結果中的 StringToSign 換行符都已經被去除。請參照文檔合理比對。

如果服務端 StringToSign 與客戶端一致，請再檢查使用的 AppKey、AppSecret 是否正確，尤其注意是否額外錯誤添加了空格等不容易發現的字符。

錯誤原因

請求傳入的 HTTP Method 或者 Path 不正確，或者請求指定的環境（X-Ca-Stage）不正確。

如指定調用 TEST 環境的 API，但 API 并未被發布到測試。

注意：

• 請求時不指定環境，默認為訪問 RELEASE 環境。

• 對 API 定義有修改，需要重新發布才能生效。許多出現這個錯誤的都是因為修改了 Path 沒發布不生效，用新 Path 請求報錯。

解決辦法

分別檢查上述三個因素：HTTP Method、Path、環境。

1. API 說明中要求用 POST 則不能用 GET 請求。Method 要一致。

2. Path 要與當前運行的一致。開放 API 的用戶經常修改之后不發布，導致調用失敗。

3. 指定環境要合理。在請求的 Header 里有個參數 X-Ca-Stage，取值 TEST/PRE/RELEASE，分別指向測試和線上環境，不傳入該參數則默認是線上。

錯誤原因

請求 API 時，使用的 AppKey 所屬的 APP 未獲得授權。無權調用 API。

解決方法

授權生效的決定因素有：APP、API、環境、已授權。

1. 如果是開放 API 的用戶自己測試，則需要在 API 網關控制臺，真實創建 APP，然后根據 AppId 在 API 列表頁操作授權。即開放 API 的用戶自測時，其實是自己需要給自己創建的 APP 授權。

2. 如果是購買了 API 的用戶，則在 APP 詳情頁可以查看該 APP 已經被授權的 API，若沒有要調用的 API，則自行操作授權。

3. 如果是使用了合作伙伴的 API，沒有購買行為的。則聯系合作伙伴。您需要提供 AppId，然后由 API 提供者操作授權。

4. 授權關系是有環境屬性的，即 APP、API都是同一個的情況下，授權的環境和請求的環境也要相同。授權了某 API 在 A 環境的權限，但是也不能調用該 API 在 B 環境中的服務。

5. 最重要的一點是，確認清楚是否用錯了 APP，是否調用錯了 API。由于 API 和 APP 較多，很多用戶因為搞混了而沒能調用成功。比如授權了 APP A，但是調用時候用的是 APP B，請仔細排查。