FedEx API 版本控制

FedEx 採用語意化版本控制來管理 API 版本。每一個版本號碼的版本格式均是「主要.次要」 (例如託運 API 1.1)。新的主要版本即代表版本改動不兼容舊版本，而新的次要版本則代表改動兼容舊版本。

FedEx 採用簡易 URI 版本控制。此方法下，URI 路徑上僅顯示主要版本的號碼。請注意，次要版本的號碼不會顯示在 URI 路徑中。此策略運用 URI 路由精確找到 API 的特定版本。

示例：/ship/v1/shipments

版本控制策略指引原則

我們計劃為 FedEx API 發佈較少的主要版本，在發佈新主要版本後兩年內淘汰上一主要版本。舉例而言，發佈主要版本「N」後，「N-1」版本將在發佈「N」版本後兩年內獲得支援。

示例：於 2020 年，主要版本 V1.0 獲發佈。如果主要版本 V2.0 在 2021 年發佈，則 V1.0 版本會於 2023 年被淘汰。

次要版本將支援大部分新的功能更新。

示例：主要版本 1.0 後，將會發佈次要版本 1.1、1.2 等等，推出全新功能更新。

不論任何時候，某一 API 的所有終端均會有同一主要版本。FedEx Developer Portal 僅會提供最新版本的文件。然而，每一個 API 概覽頁面底下都會有改動記錄，詳細列出主要及次要版本的變動。

API 主要版本會在甚麼時候發佈？

我們致力減少 API 的主要版本數目。然而，有時候難以避免需要推出全新的主要版本。下列會需要發佈全新主要版本的部分關鍵原因：

• 請求或回應中的現有計算數值被移除，或是其格式或數值被改動時
  

  示例：locationSearchCriterion 元素的計算數值「GEOGRAPHIC_COORDINATES」在 N 版本中遭移除；日期語法從年-月-日改為月-日-年；將回應下服務站類型從 FEDEX_ONSITE 改為 ONSITE

• 請求或回應中的現有元素被移除時
  

  示例：報價請求內的 pickupType 元素在 N 版本中遭移除 (或改名)

• 現有方法被移除時
  

  示例：N 版本已不再支援建立及取消 FedEx Express 標籤的方法

• 請求中將以往非必要或有條件的現有元素改為必要時
  

  示例：N 版本中，FedEx Express® 託運貨件的預約號碼現在是必要元素

• API 設計出現改動時
  

  示例：重新排列請求及回應的結構

• 錯誤代碼及錯誤訊息出現改動時
  

  示例：將錯誤代碼 INCORRECT.WEIGHT 改為 WEIGHT.LIMIT.EXCEEDED

API 次要版本會在甚麼時候發佈？

• 新增新的計算數值時
  

  示例：N 版本中，serviceType 元素將新增新的運輸選項

• 新增新的元素時
  

  示例：推出全新非必要元素，以包含國際貨件的清關代理人電話號碼

• 新增新的方法時
  

  示例：N 版本新增方法，以在上載國際貿易文件後進行修改。

• 將以往必要的現有元素改為非必要時
  

  示例：文件 ID 現在為非必要項目，因為 FedEx 能基於用戶資訊取得文件 ID。