在Spring-Data-Rest中，对象的ID是随对象返回的URI。例如，如果我有一个User，它可能有一个像：
这样的URIhttp://example.com/users/1
在一个真实的REST api中，这个URI是对象的id，你不应该只使用＆＃39; 1＆＃39;作为id。
说明，如何搜索属于该用户的所有订单？
http://example.com/orders/search/findByUser?user={{XXX}}
具体来说，我对{{XXX}}使用了什么？
我知道我可以进行相反的搜索：
http://example.com/users/1/orders
但在我的情况下，我需要搜索匹配的作业，这样我就可以添加其他参数，这也是键。
我可以通过在OrderRepository上创建此函数定义来导出/orders/search/findByUser：
列出findByUser（用户用户）;
和findByUser将由Spring-Data-REST导出，但如何将User指定为GET参数？
同样，我特意寻找纯REST解决方案，因为Spring Data Rest项目正试图鼓励纯度。
答案 0 :(得分：3)
您可以查看Spring数据的Query注释。它使您无需自定义控制器即可执行自定义查询。
修改
查询参数是通过简单属性过滤资源的好方法。由于SDR将所有复杂类型序列化为关系，因此过滤仅适用于剩余（简单）属性更为清晰。
如果您只有一个关系，那么您正确地提到了使用/users/1/orders进行“反向”搜索的方式。
如果您想通过多种关系进行搜索，我建议您定义一个单独的搜索（子）资源，并通过向该资源发出POST请求来执行搜索。
例如：
POST /orders/search
{
"user": "http://example.org/users/1",
...
}
这样，SDR会正确地将URI转换为实体。但是，我认为您需要在此处使用自定义控制器，但仍应使用Spring Data存储库并将用户和其他实体作为参数提供。
有关详细信息，请参阅以下SO问题：
How to design RESTful search/filtering?
RESTful URL design for search
<强> EDIT2：
解决使用POST进行搜索的问题违反了REST规范：
REST的设计很简单。 REST的一个主要优点是您不会被迫做任何事情。您可以调整规格，直到它符合您的需求。当然，这可能意味着您的API不那么REST，但是如果它为您的API的消费者带来了不必要的开销，那么您应该考虑是否值得严格遵守规范。
当然，您可以将上述想法设计为完全符合REST规范。这将涉及创建一个单独的搜索实体，将其持久化到数据库，然后通过调用像/result之类的子资源或类似的东西来检索搜索结果。但问题是，如果值得的话。
在您的具体示例中，我只需要客户端从链接中解析ID并将其作为查询参数提供。如果您稍后要扩展应用程序，可以引入命名搜索等功能并应用上述解决方案。
答案 1 :(得分：0)
如果您使用控制器，就像您的情况一样，您可以传递您认为必要的任何参数。看看这个问题：
答案 2 :(得分：0)
请参阅https://jira.spring.io/browse/DATAREST-502
根据您的Spring Data版本，它可以根据您的需要而定。 顺便说一下，我仍然认为POST也应该是一个选项，它会更清晰。