2009-11-05 69 views
15

我爲我的客戶提供了一個小型的Web服務API,我打算隨着時間的推移而發展。所以我需要某種版本控制,但是我找不到任何關於如何做這種事情的信息。Web服務API版本

是否有最佳做法?

如何不斷開添加新功能而不破壞與Web服務使用者的兼容性?

回答

0

在所有API中添加「API版本號」作爲參數,然後在您的Web服務代碼中實施策略模式,其中版本號指示要使用的策略。

+4

這樣的工作只有在版本的Web服務需要*準確*的相同的參數,所以相同的WSDL適用。如果在新版本中需要增加一個新屬性,你會怎麼做? – 2009-11-05 10:57:03

1

我通常會將版本字符串添加到Web服務URL中,給我「版本化的端點」。實現這些端點的代碼可以是共享的,如果差異很小並且可以由相同的代碼處理,或者代碼可以被克隆,或者介於兩者之間。

不同版本的端點也可以使用版本化的XML模式,如果這是您所需要的。

18

版本控制是一個複雜的主題,首先,您需要以更具描述性的方式定義您的目標。很高興地說,你有一個接口可以確保你永遠不會破壞兼容性,但取決於新功能是什麼,這可能甚至是不可能的。所以有不同的情況和不同的權衡。如果您的意圖是僅向新消費者提供新功能,並且您的所有消費者都是直接消費者(無中間人,框架等),那麼離散終端方式是最佳選擇。每次添加可能會中斷的功能時,請創建一個新端點,併爲其指定一個新版本號,然後讓消費者知道對其進行驗證並切換其配置。這種策略相當有成效,但存在消費者負擔不斷增加的缺點。另外,如果服務之間存在依賴性,它可能成爲一件難事。如果代碼被打破,它不會(直接)成爲你的錯。

另一個主要策略是可擴展接口。我知道這裏有三種不同的品種。首先,試圖很好地描述服務領域的接口類型使得在給定現有接口的情況下,您可能添加的每個可能功能都是可能的。如果這聽起來很難,它是。你可以稱之爲完美的界面。一切都完全描述,但整個領域也完全描述。儘管「完美」只是在紙上。

第二種是類似於普通界面的類型,但添加了通用擴展點。在WSDL中,這意味着xs:any,名稱 - 值對或類似的東西。您可以將其稱爲基本的可擴展接口。這並不難,但它並非沒有複雜性。擴展點可能會使界面在某些工具(xs:any)中難以使用,或者顯式地失去了一些驗證輸入和輸出(名稱 - 值對)的能力。濫用這些擴展點使3或4版很難使用也很容易。

第三種是將接口轉換爲字節流的類型。你可以稱這些神界面。他們並非沒有理由,但如果你使用了一個,你可能會問爲什麼你使用網絡服務。也許你應該考慮原始的TCP/IP或基本的HTTP GET/POST。但是,也許你厭倦了WSDL和XSD的複雜性,你只是想從頭開始,但是出於某些基礎設施的原因,你被綁定到了Web服務。然而,要意識到,一旦你開始了這條道路,你需要一種全新的方式來向消費者描述如何/不使用你的服務,如果你使用XSD,那麼你基本上就回到了那裏你開始了。

最好的選擇是通過首先嚐試「完美界面」,然後放棄並添加通用擴展點,來了解所有這些選項並接近您的服務設計。試圖設計完美的界面將迫使你學習能讓你的服務更好的東西,而不僅僅是你的界面,但這需要時間,而且如果你不以某種方式限制這個時間,它將會持續下去。

有點缺乏真正的神界面,有包裝界面。如果您的系統具有圖層,則您希望您的界面也處於分層狀態。當您更改圖層B時,您只想更改圖層B,而不是圖層C中的所有實例。

+1

所有的一些抽象和天空餅爲我喜歡。 – 2011-05-17 14:18:59

+4

考慮到原始問題中提供的信息,他究竟應該如何確定最具體的? – HDave 2012-01-13 02:20:04

1

其中一種可能性是將所有Web服務操作設計爲只有一個從某些抽象繼承的類型參數保存版本號的類型。該方法由eBay web services platform實施。 類似以下內容:

<xsd:complexType name="AbstractRequestType"> 
    <xsd:attribute name="version" type="string" /> 
    .... 

<xsd:complexType name="AddCustomerRequestType"> 
    <xsd:complexContent> 
    <xsd:extension base="AbstractRequestType"> 
    .... 

then use AddCustomerRequestType as a type of only parameter 
in addCustomer web service operation. 

此外,如果你工作在HTTP上你可能需要添加版本作爲HTTP GET參數到Web服務端點的URL,這樣你就可以很容易地檢測請求版本 http://server/service?version=1

5

是我見過的最常見的策略是版本的WSDL加入版本識別(通常yyyy/MM[/dd])對象的WSDL中的命名空間,即:

targetNamespace="http://schemas.mycompany.com/2010/01/widgets" 

這可以在每個typetypes/schema)級別完成,也可以在整個WSDL級別完成,即1.1或<description>(2.0)中的<definitions>

有些過時,但是從IBM開發this link工作提供了這種方法的基本原理,以及特別是當版本需要遞增:

向後版本compatable /非破壞性變更:

  • 添加新操作
  • 添加新類型

重大更改:

  • 刪除或重命名操作
  • 更改參數的方法
  • 更改複雜類型