REST - GET返回與POST/PUT不同的結果

在我們的項目中，可以通過POST或PUT請求發送書籍結構（使用XML，JSON，..）來添加書籍。例如，在XML中，書結構如下所示（簡化）：REST - GET返回與POST/PUT不同的結果

<book> 
    <title>My Book</title> 
    <author>John Q.</author> 
</book>

當這本書被插入在我們的後端數據庫，一些自動生成的屬性被自動添加，如創建日期，用戶誰提交書籍，標識，...

當這本書是通過GET檢索到的ID，這些額外的屬性包含在書中的定義：

<book> 
    <title>My Book</title> 
    <author>John Q.</author> 
    <info> 
     <creation_date>2011...</creation_data> 
     <user_id>48</user_id> 
     <identifier>my_book_john_q</identifier> 
    </info> 
</book>

這基本上意味着的XML方案一本新的/編輯過的書（=從客戶到s erver）不同於檢索到的書（=從服務器到客戶端）。這使事情混亂。

成爲了可能，是使在不同的URI提供這些額外的屬性，例如：

http://server/books/:id/    -> returns the short version 
http://server/books/:id/information/ -> returns the generated properties

這種方法的一個缺點是，需要兩個單獨的請求到擁有所有數據。

你會如何解決這種不一致？

來源

2011-07-16 Appelsien S.

這是完全正常的。服務器使用一些附加信息來增加表示法是沒有問題的。一個很好的例子就是當服務器添加鏈接到表示。在做PUT時，客戶端不需要將這些鏈接的「副本」發送到服務器。 GET和PUT的資源表示應該在概念上相同，不一定是字節相同的字節。

來源

2011-07-16 19:28:33

好的。事實上，我不確定GET和PUT在概念上還是內容方面必須是相同的（逐字節）。 –

我同意：模式爲我們服務;我們不爲他們服務。 tl; dr：emerson BTW：你知道這種模式的起源或支持者嗎？ –

您沒有正確使用mimetypes。我敢打賭，你正在使用一個application/xml通用MIME類型，你的客戶知道基於端點的期望，對嗎？

處理您的問題的正確方法是對不同的mimetypes具有相同資源的不同表示。例如，您可以使用application/vnd.yourcompany.book.short+xml作爲簡短表示，使用application/vnd.yourcompany.book+xml作爲完整表示。客戶可以使用Content-Type標題來說明他們正在發送哪一個，並使用Accept標題來說明他們想要哪一個。

這並不意味着客戶端必須在POST或PUT中發送短表示。您可以將一些字段記錄爲可選字段，客戶可以忽略它們。

來源

2015-11-24 19:41:19

REST - GET返回與POST/PUT不同的結果

回答

相關問題