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对于一些复杂的查询。