2010-11-01 69 views

回答

2

這是一個很難回答的問題,主要是因爲在目前的行業狀況下,正確的答案是非常不切實際的。

在我看來,正確的答案是你不應該使用包裝API。統一的接口是HTTP,並且應該是客戶端針對的編程模型。

話雖如此,讓解析媒體類型來生成強類型版本的助手類沒有什麼問題。就像這樣,

var response = HttpClient.Get(linkTofoo); 
if (response.ContentType =='application/foo') { 
    var strongFoo = FooHelper.Parse(fooResponse); 
    HandleFoo(strongFoo); 
} 

不幸的是,絕大多數聲稱是RESTful的apis都不是。他們不尊重自我描述和超媒體約束,因此他們很難以RESTful的方式與他們交互。它們要求您執行客戶端URI構造,並且事先知道將從端點返回的類型。

令人遺憾的事實是,在許多API中,您別無選擇,只能使用提供的客戶端代理庫。這不應該是這樣。

如果您正在尋找評估客戶端庫,請確保它是無狀態的。客戶端庫不應該開始管理返回對象的生命週期。 Http緩存就是這樣做的,所以除非它是一個超級智能庫,當緩存表示過期時可以使對象引用失效,否則應避免使用任何有狀態的客戶端庫。

e.g. 

var foo = remotelibrary.GetFoo(233); 
var bar = foo.bar; // If this causes an HTTP request 
var barcopy2 = foo.bar // and this doesn't because it already has a reference to bar 
         // I would be very leary of using this library 
+0

我會說可以編寫/使用爲特定超文本應用程序編寫的庫,例如AtomPub – Mike 2010-11-01 14:04:25

+0

@Mike是的,如果這個庫是爲HTTP上的特定協議編寫的,那麼很可能它會在封面下正確使用HTTP,所以你應該是安全的。 – 2010-11-01 14:38:57

1

從長遠來看,使用庫幾乎肯定會更好。這使您可以抽象出設計的寧靜,並忽略整個HTTP業務。

如果您使用的任何API都不存在現有的庫,那麼您應該考慮編寫自己的API。

相關問題