REST風格的API設計。如果請求帶有過濾器，您是否也應該返回該過濾器的值？

可以說客戶端的GET請求/ items/color/{color}REST風格的API設計。如果請求帶有過濾器，您是否也應該返回該過濾器的值？

當服務器返回具有所述顏色的對象數組時，每個item對象是否都有顏色屬性？

客戶端知道返回項目的顏色，因爲他請求顏色，所以服務器是否應該嘗試使響應大小更小或不響應？

編輯：人們可以更多地節省帶寬部分？如果最好能夠返回整個資源，答案可以包括爲什麼返回整個資源與節省帶寬相比更好，而不是爲什麼應該返回整個資源。

來源

2016-11-07 Erndob

一般來說（至少這是REST的理念，據我所知），請求的結果應始終爲完整資源。如果該項目包含成員color，則沒有理由在結果中禁止該成員。這與REST資源的概念相矛盾。資源不會更改其屬性。

抑制成員不僅會意外，甚至可能在客戶真正期望該成員時破壞客戶。

讓我們假設客戶端有功能來解析您的REST調用的結果而無需過濾器。所有字段將被返回，客戶端將解析所有字段。現在客戶端請求完全相同的資源（item），但突然間字段不同 - 從上面解析結果的代碼不能被重用。

另外，當你考慮它時，可能會有更多的工作壓制該成員，而不是僅僅返回它。

來源

2016-11-07 13:17:14

那麼，你會有文檔。如果你描述了這種行爲，並且它在你的api中是一致的，那麼它不會是真正意想不到的，不是嗎？另外，節省帶寬怎麼樣，你能接觸到嗎？這沒關係嗎？在web開發中，人們真正關心每個kb，因此縮小響應大小，因此加快應用程序似乎很重要。差異顯然會越大，返回的數組越大，過濾器越多，我認爲在某些情況下，這可能非常重要。重複相同的信息客戶端已經知道在每個對象看起來很浪費。 – Erndob

資源應該包含相同的字段，而不管它是如何獲取，過濾或不是。這就是我對REST的理解。當然你可以自由地實現你想要的任何東西。大小確實很重要，但是您的示例可以保存什麼 - 20個字節？我要做的是：允許客戶端指定應該返回的字段。在這種情況下，客戶端負責節省帶寬。 –

沒有「正確的」答案，這取決於一般的API設計，應該是您的決定。

我同意Thorstens的意見，你應該返回整個資源 - 這是接近一般REST的想法。當你這樣做時，你也可以實現一些像在FB API中一樣選擇字段的機制：請參閱this paragraph的「選擇字段」部分。

來源

2016-11-07 13:19:19

您應該在回覆中保留顏色。將會有多個方面的原因：

你確保你所請求的就是你
如果有在頁面不同顏色的多個項目，你不要讓客戶照顧根據顏色「過濾」物品
您有更「安全」的迴應。例如，客戶端請求藍色，但是然後惡意腳本會以紅色項目操作此響應。

來源

2016-11-07 13:21:28

爲什麼客戶會重新回覆？它被過濾了服務器端，客戶端期望所有返回的項目都是「紅色」，否則服務器代碼被破壞 – Yazan

您不必重新過濾響應，但客戶端有責任知道來自響應。 –

客戶端將已經在URL'.../items/red'中發送過濾器數據，所以客戶端不必重新檢查響應（是我要求的嗎？） – Yazan

REST風格的API設計。如果請求帶有過濾器，您是否也應該返回該過濾器的值？

回答

相關問題