在REST api中支持通用查询条件的缺点

Question

我想知道让一个REST API支持各种查询约束的权衡是什么。我正在考虑Parse之类的API的作用。

Parse采用REST，允许几乎完全在客户端构建一个DB语句，我想象在服务器上他们有一个引擎，将where: {} JSON键转换为包含所有已定义条件的适当Mongo查询。例如，可以这样做:

curl -X GET 
  -H "X-Parse-Application-Id: xxx" 
  -H "X-Parse-REST-API-Key: xxx" 
  -G 
  --data-urlencode 'where={"hometown":{"$select":{"query":{"className":"Team","where":{"winPct":{"$gt":0.5}}},"key":"city"}}}' 
  --data-urlencode 'limit=200' 
  --data-urlencode 'skip=400' 
  https://api.parse.com/1/classes/_User

从数据部分可以看到，通过使用这个非常灵活的系统，可以在客户机上生成一些相当复杂和有趣的查询。现在让我们假设您不是使用Parse，而是使用SQL，并且您的(私有的!)API的要求并不是支持客户端可以进行的所有类型的查询，但是您仍然可以在这里或那里定义一些约束，以避免向客户端发送它不会使用的数据，因为它不能以足够的精度定义查询。

在上述情况下，db语句生成引擎方法是否只是一种过度使用?如果是这样，有什么更简单的方法来处理让不同的资源共享一些约束(如限制、跳过、排序)，但不是所有约束?有些可能是特定于该资源的。这里有关于各种设计决策的优秀资源吗?

Answer 1

如果需要RESTful架构，则需要使用HATEOAS，这意味着需要根据先前响应中发送的表示生成查询。因此，"db语句生成引擎"是不必要的，因为所有可以设置的选项都将作为模板由服务器提供(例如HTML表单，但在您的情况下可能更复杂，可能是自定义内容类型中的XForms)。约束将由表单输入标记定义。选择一种足以向客户端描述所有约束的标记语言。