1

我想知道让一个人的 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 语句生成引擎方法是否只是矫枉过正？如果是这样，处理让不同资源共享一些约束（如限制、跳过、排序）但不是全部约束的更简单方法是什么？有些可能特定于该资源。有什么很棒的资源可以在这里讨论各种设计决策吗？

4

1 回答 1

1

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

于 2013-06-10T10:37:25.950 回答