2012-09-17 47 views
1

我一直想知道在REST中使用多少鏈接。考慮有作者的書籍,但書籍和作者之間顯然存在多對多的關係(一本書可以由多個作者編寫,作者可以編寫多本書)。REST和鏈接:中間地面?

假設我們有一個休息電話http://server/book/21,它將返回一本書XML,其中包含有關作者的信息。由於本書是資源,作者是資源,因此XML不應直接包含所有作者信息。它應該包含一個作者信息的鏈接。但是,下面兩個例子中的哪一個更廣泛被接受?

(請原諒我糟糕的格式化XML,我不是用手寫XML有經驗)

<book> 
    <title>Some Book</title> 
    <authors> 
    <author link="http://server/author/82">Some Guy</author> 
    <author link="http://server/author/51">Some Other Guy</author> 
    </authors> 
</book> 

然後,作者鏈接將返回更多信息:

<author> 
    <name>Some Guy</name> 
    <dateOfBirth>some time</dateOfBirth> 
</author> 

或者:

<book> 
    <title>Some Book</title> 
    <authors>http://server/book/21/authors</authors> 
</book> 

其中http://server/book/21/authors返回:

<authors> 
    <author link="http://server/author/82">Some Guy</author> 
    <author link="http://server/author/51">Some Other Guy</author> 
</authors> 

然後每個返回前面的<author>例子。

我問的原因基本上是因爲在我的工作中,他們採用第二種方法,在我看來,客戶必須採取更多步驟才能到達他們想要去的地方。此外,對於「你總是需要」(作者姓名)的基本信息,你必須採取一個額外的步驟。 另一方面,book資源只能返回關於本書的信息(沒有其他),並且獲得其他任何內容,您必須訪問其他資源。

回答

1

這個問題聽起來更像是一個「你喜歡什麼」類型的問題。所以這裏是我的2美分:

在我看來,包括作者姓名在原來的XML將是最好的主意。這將允許客戶端應用程序顯示可熱連接的作者姓名列表,而不需要第二個休息請求。作者姓名最有可能總是在圖書資源時顯示。如果我是你,我會更關注實用性,而不是擔心其他資源的「理論」正確性。如果那有意義的話。

您不必在原始xml資源中包含作者的所有信息。相反,顯示書籍資源的實用性,以及何時/如果需要,可以找到有關作者的更多信息。

0

只要它的一貫做....

無論是看起來很好,但我居然把我的錢第二種方法更靈活,允許以一致的方式未來的API成長。這是因爲你可能與主對象之間的關係不止一個對象。用大量的鏈接指向不同的對象來獲取單個對象可能是一件痛苦的事情。此外,它將對象的大小限制爲只返回核心「書籍」信息,而不是與其相關的其他各種對象,即使它們看起來不起作用。爲每個資源尋找最小的有用組件,至少可以減少後端的不必要的負載,以及不會真正使用的關係。

當然,在這個例子中,很難看到限制關係信息在對象中的重要性,因爲大多數書籍最多隻有少數幾個作者,但是您通過REST公開的所有對象的情況如何?試想一下,如果這是一家「書店」,而且這種關係是「顧客」。如果您只是想要店鋪地址和電話號碼,那麼對於各方您還需要將客戶的完整列表撤回並將其作爲對象的一部分,這對於所有各方來說都不是很浪費?因此,您對這種新情況作出例外,而不是將客戶作爲鏈接返回,但對於您決定將其作爲鏈接包含在內的另一件事情,例如商店部門?現在你有了不一致的現象,你的客戶需要了解每個對象返回的方式,因爲它們都不符合相同的模式。

如果在整個API中普遍使用相同的方法,第二個方法也會保持關係模型的清潔。任何物體的關係都可以通過以下方式訪問:

http://server/object/<object_id>/<relationshipName> 
+0

爲了一致起見,這是有道理的。雖然,如果我正在爲此xml數據編寫客戶端應用程序,我會對額外的步驟感到沮喪。在他最初的例子中,我必須首先訪問本書,然後訪問關係,然後作者訪問任何給定書籍的作者姓名。我想這實際上取決於客戶的需求。 – demersus