REST API設計查詢

Question

我在決定在這種情況下在REST API設計中如何處理時遇到問題。

這裏是我的問題，

我有一個資源領域模型，其中有一個嵌套的對象，這也是一個域模型。

你能想象這樣的事情

{ 
"name":"abc" 
"type":{ 
     "name":"typeName", 
     "description":"description" 
     } 
} 

現在，我希望能夠獲取外部資源模型，基於內部模型和幾個PARAMS上。

例如，我希望獲取具有給定類型和一些PARAMS像網頁數量，規模等

所以我的問題所有外模型資源，

1. API應該接受內部模型，並返回外部模型，這是一個很好的休息設計？

1. 如何傳遞額外參數？這是一個POST，不能把它們放在URL中，也不能把它們放在內部模型中。

我應該創建一個新的模式，它包含這些額外參數和資源類型也？ 像

{ 
"page":"10", 
"type":{ 
     "name":"typeName", 
     "description":"description" 
     } 
} 

Answer 1

如果你是一個普通的HTTP服務，這是可以接受的使用POST發送複雜的查詢，並得到迴應。

如果您試圖成爲RESTful，那麼這是一個不好的做法。你有兩個選擇。選項1是找到一種在URL中對查詢進行編碼的方法，因此您可以使用GET請求。

選項2更多參與。我不一定會說我會提出這個建議，但它是一種在複雜查詢時避開REST約束的方法。

這個想法是，您使用POST來創建'查詢'資源。就好像你在做一個服務器端準備好的語句，然後用GET來獲得查詢結果。客戶端 - >服務器會話

例子：

POST /queries 
Content-Type: application/json 
... 

爲了對此作出迴應可能是：

HTTP/1.1 201 Created 
Location: /queries/1234 
Link: </queryresults/1234>; rel="some-relationship-identifier" 

然後之後，你可以做一個GET /查詢/ 1234看查詢你'準備好'和GET在/queryresults/1234查看實際報告。

這樣做的好處是它保持在REST的約束範圍內，並且您可能會重新使用查詢並花費較長時間來生成結果。

一個明顯的缺點就是很難向API的使用者解釋這一點，因爲不是每個人都可能熟悉這種模式，並且這是一個額外的HTTP請求。

所以，你必須決定：

• 是否值得這樣做呢？
• 你可以編碼URI中的查詢，而不是爲了避免這種完全
• 也許你不關心是基於REST足夠的，你可能只是想打破規則，並使用POST對於一些複雜的查詢。