REST API - 媒體類型參數中的屬性過濾器

Question

我想尋求一些關於設計REST/hipermedia API的建議，特別是關於使用框架實現的建議。

取而代之的是一般的'實體'的例子，我會用一個更平凡的'文檔'實體。

問題1：

GET /document/?[query] 

得到的文件清單。問題在於「文檔」只有幾十個屬性，在很多情況下，客戶端只會關注少數幾個（特別是在此次搜索中） - 響應的大小可能會有幾個（最多10次）不等，而且服務器查詢可能會更快。另外，我不得不提到，我們更喜歡無模式。

我發現樣品如

GET /document/attr1, attr2../?[query] 

我覺得這完全是非REST-FUL。

另一篇文章是建議使用內容類型（實際上接受，因爲它是請求），但是例子丟失了，仍然有混合的感覺。喜歡的東西：

Accept: application/json; attrs="attr1,attr2" 

我不知道這是否是尊重HTTP的語義，並且如果這種使用的媒體類型參數是合適的（畢竟我要資源的不同表現 - 與某些屬性過濾掉）。

問題2：

如果上面或多或少aceptable的解決方案，我不知道是否有什麼準備django-rest關於自定義介質類型的屬性解析。從我在文檔中可以看到的信息來看，媒體類型參數不是單獨解析（或處理）的。

編輯

一些額外的信息：應用程序的很大一部分是OLTP（帶不會緩存）。架構是帶有靜態文件的JSON服務器，JS重型客戶端。

編輯2

其實，我發現了一些意見，在他們的自然搜索是新的（揮發性）資源（結果）創作，所以POST方法是比較合適的。這消除了討論中的問題。我對創建的實體（結果）有一些問題，因爲我不想堅持它，但我認爲這不是強制性的。問題是要在「位置」標題中添加什麼內容（僞造URL，沒有位置標題或其他內容）？對我來說唯一一致的行爲正是我不想做的 - 搜索POST執行搜索，將結果存儲在服務器端並返回201並鏈接到它。然而，這是沒有道理的持久負載...

關於瀏覽器測試，MIME類型text/html可能會提供一個用戶友好的搜索表單。

Answer 1

建築風格告知架構，這些架構限制了隨後實現的設計。 REST是一種建築風格。您很難設計一個URI，這並不是因爲實現選項有限，而是因爲架構不匹配。您的客戶希望通過減少消息的大小來最大限度地提高效率。但是您選擇的架構風格（REST）uses caching to maximize efficiency自然會導致更大的消息（因此資源更少）。如果你的架構不使用緩存來最大限度地提高效率，它就會偏離REST風格（並且可能會創造一種新風格; Roy應該對這種非常常見的風格進行架構分析）。

解決方案是選擇不同的架構風格（RPC通過減少消息的大小來最大限度地提高效率），或者影響客戶端需要REST，因爲它帶來了：可伸縮性，簡單性，效率，可演化性和用戶友好性，感知的表現。