與數據模型相比，API的返回數據應該簡化多少？

我正在設計一個有點REST風格的API，並且數據模型相對複雜且規範。 API的返回數據應該多簡單？與數據模型相比，API的返回數據應該簡化多少？

它是更好的做法，從相關表與實際數據來代替外鍵或ID，或者是更好的做法，回到什麼是數據庫，並提供API方法把這些ID爲可用的內容？或者......除了可用數據之外，是否還提供ID？

下面是在返回數據的數據庫原始數據的例子：

<books> 
    <book-id>935</book-id> 
    <book-author-id>64</book-author-id> 
    <book-genre-id>5</book-genre-id> 
</books>

這裏只返回可用內容的一個例子：

<books> 
    <book-name>Steve Jobs</book-name> 
    <author-name>Walter Isaacson</author-name> 
    <book-genre-name>biography</book-genre-name> 
</books>

來源

2012-02-08 Scott Hildebrand

這真的要取決於如何你數據將被使用。一般來說，無論何時您需要深入細節，您都需要提供可以使用的URL或ID。

對於你的榜樣，題目是不是你很可能需要不斷提供更詳細的東西，所以你可能只是安全直接包括它。流派也不需要更多細節，但人們可能想要獲取該類型的所有其他書籍。

作者幾乎可以肯定你想要更多的細節，都履歷信息，並通過他們找到其他書籍的東西。不僅如此，雖然您的流派字段不可能包含重複的名稱，但您的作者肯定會。

作者本身應該是一種資源。所以應該流派。都與他們的鏈接。

對於真實世界的API設計，您需要進行非規範化的資源一點點。加入地獄超過http。假設幾乎所有提取書籍的人都會想要作者姓名，那麼應該將其包含在書籍資源中。他們可能還需要關於作者的其他信息，比如他的照片。

因此，對於你的榜樣API，我們在這樣的事情到了... ...

<books> 
    <title>Steve Jobs</book-name> 
    <author href="http://example.com/author/64"> 
     <name>Walter Isaacson</name> 
     <photo>http://images.example.com/author/64/photo</photo> 
    </author> 
    <genre href="http://example.com/genre/5">biography</genre> 
</books>

不要讓開發者將如何使用您的API太多的假設。關於API的一個很棒的事情是開發人員開始使用它來創建你從未想過的事情。給他們的原始工具，看看發生了什麼樣的真棒。

來源

2012-02-11 00:49:38

假設通常可能有多個作者，你會選擇總是擁有一個支持多個「作者」的「作者」元素嗎？ – 2012-02-11 01:42:34

嗯，當然。你可以做的任何事情來更容易地解析數據總是更好。當試圖決定在你的api中包含什麼時，選擇冗長。 – 2012-02-11 03:12:14

我一般說，你的API應該滿足API的用戶的要求。特別是，「揭示數據模型」不是一個好目標。實際上，您可能會公開一些數據模型的某些部分，或許是簡化的，以滿足要求。但是，無論是否暴露外鍵的全部答案都將完全取決於要求。

來源

2012-02-11 01:54:36

與數據模型相比，API的返回數據應該簡化多少？

回答

相關問題