Question

我想知道让一个REST API支持各种查询约束的权衡取舍。我正在考虑API like that of Parse的作用。

Parse对REST的看法允许人们几乎完全在客户端上构建一个DB语句，我想在服务器上他们有一个引擎将where：{} JSON密钥转换为一个包含所有定义的条件。例如，这是人们可以做的事情：

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）。约束将由表单输入标记定义。选择足以描述客户端所有约束的标记语言。

缺少支持REST API中的通用查询条件？

1 个答案: