5

我认为我的问题可以用几个例子更好地解释......

GET http://myservice/myresource/?name=xxx&country=xxxx&_page=3&_page_len=10&_order=name asc

也就是说，一方面我有条件（ name=xxx&country=xxxx ），另一方面我有影响查询的参数（ _page=3&_page_len=10&_order=name asc ）

现在，我想使用一些特殊的前缀（在这种情况下是“_”）来避免条件和参数之间的冲突（如果我的资源有一个“订单”属性怎么办？）

有没有一些标准的方法来处理这些情况？

--

我找到了这个例子（只是挑一个） http://www.peej.co.uk/articles/restfully-delicious.html

获取http://del.icio.us/api/peej/bookmarks/?tag=mytag&dt=2009-05-30&start=1&end=2

但在这种情况下，条件字段已经定义（没有开始或结束属性）

我正在寻找一些通用的解决方案...

-- 编辑，一个更详细的例子来澄清

每个项目都是完全独立的......假设我的资源是客户，并且（幸运的是）我的数据库中有几百万个。

所以网址可能类似于

http://myservice/customers/?country=argentina,last_operation=2009-01-01..2010-01-01

它应该给我去年买过任何东西的所有阿根廷客户

现在我想使用这个服务来构建一个浏览页面，或者用 ajax 填充一个组合，所以我的想法是添加一些元数据来控制我应该得到什么信息

构建我要添加的浏览页面

http://...,_page=1,_page_len=10,_order=state,name

并用 ajax 填充自动建议组合

http://...,_page=1,_page_len=100,_order=state,name,name=what_ever_type_the_user *

用与用户键入的内容匹配的前 100 个客户填充组合...

我的问题是，是否有某种标准（书面或非书面）方式以一种完整的 url 方式对这类内容进行编码......

4

4 回答 4

5

虽然没有标准，但Web API 设计（Apigee 出）是创建 Web API 时的一本很好的建议书。我将其视为一种标准，并尽可能遵循其建议。

在“分页和部分响应”下，他们建议（第 17 页）：

使用限制和偏移

我们建议限制和抵消。它更常见，在领先的数据库中很容易理解，并且对开发人员来说很容易。

/dogs?limit=25&offset=50
于 2013-11-12T10:02:34.100 回答
2

没有标准或约定来定义执行此操作的方法，但是使用下划线（一个或两个）来表示元信息并不是一个坏主意。这是在某些语言中用于按约定指定成员变量的内容。

于 2009-05-30T13:32:26.713 回答
2

注意： 我开始写这篇文章是对我之前的回答的评论。然后我打算将其添加为编辑，但我认为它属于单独的答案。这是一种完全不同的方法，并且本身就是一个单独的答案，因为它是一种不同的方法。

我考虑得越多，我认为您确实有两种不同的资源需要处理：

  1. 一页资源
  2. 收集到页面中的每个资源

我可能错过了一些东西（可能是......我犯了误解）。由于页面本身就是资源，因此分页元信息实际上是资源的属性，因此将其放在 URL 中不一定是错误的方法。如果您考虑可以为页面下游缓存的内容和/或将来称为资源的内容，则资源由分页属性和查询参数定义，因此它们都应该在 URL 中。为了继续我完全冗长的回复，页面资源将类似于：

http://.../myresource/page-10/3?name=xxx&country=yyy&order=name&orderby=asc

我认为这触及了您最初问题的核心。如果页面本身是一个资源，那么 URI 应该描述页面，所以就像page-10我所说的“一页 10 个项目”，页面的下一部分是页码。查询部分包含过滤器。

其他资源命名页面包含的每个项目。如何识别项目应该由资源是什么来控制。我认为一个关键问题是结果资源是否独立存在。根据此概念，您表示项目资源的方式会有所不同。

如果项目表示仅在页面上下文中是合适的，那么包含内联表示可能是合适的。如果您这样做，则单独识别它们并确保您可以使用URI 片段语法或附加路径元素检索它们。似乎以下 URL 应导致十项的第三页上的第五项：

http://.../myresource/page-10/3?...#5
http://.../myresource/page-10/3/5?...

在这两者之间做出决定的最大因素是单个项目与页面的耦合程度。片段语法比路径元素恕我直言更具约束力。

现在，如果项目资源是独立的并且页面只是查询的结果（我认为这里很可能就是这种情况），那么页面资源应该是每个项目资源的 URL 的有序列表。在这种情况下，项目资源应该独立于页面资源。您可能希望使用基于项目本身的标识属性的 URI。所以你最终可能会得到类似的东西：

http://.../myresource/item/42
http://.../myresource/item/307E8599-AD9B-4B32-8612-F8EAF754DFDB

关键的决定因素是这些项目是否是独立资源。如果不是，那么它们是从页面 URI 派生的。如果它们是独立的，那么它们应该由它们自己的资源定义，并且应该作为链接包含在页面资源中。

于 2009-05-31T15:11:12.013 回答
1

我知道 RESTful 的人倾向于不喜欢使用 HTTP 标头，但有没有人真正研究过使用HTTP 范围来解决分页问题。几年前我写了一个 ISAPI 扩展，其中包括分页信息以及 URI 中的其他非属性信息，我从来没有真正喜欢它的感觉。我正在考虑做类似的事情：

GET http://...?name=xxx&country=xxxx&_orderby=name&_order=asc HTTP/1.1
Range: pageditems=20-29
...

这会将结果集参数（例如_orderby和_order）放在 URI 中，并将选择作为Range标题。我有一种感觉，尽管大多数 HTTP 实现都会搞砸这一点，特别是因为对非字节范围的支持是 RFC2616 中的一个 MAY。在使用RTSP做了很多工作后，我开始更加认真地思考这个问题。RangeRTSP中的标头是扩展范围以处理时间和字节的一个很好的例子。

我想另一种处理方法是对页面上的每个项目单独请求作为单独的资源。如果您的代表允许这样做，那么您可能需要考虑它。中间缓存更有可能与这种方法一起工作得很好。因此，您的资源将被定义为：

myresource/name=xxx;country=xxx/orderby=name;order=asc/20/
myresource/name=xxx;country=xxx/orderby=name;order=asc/21/
myresource/name=xxx;country=xxx/orderby=name;order=asc/22/
myresource/name=xxx;country=xxx/orderby=name;order=asc/23/
myresource/name=xxx;country=xxx/orderby=name;order=asc/24/

我不确定是否有人尝试过这样的事情。这将使 URI 可构造，恕我直言，这始终是一个有用的属性。这种方法的好处是可以缓存各个响应，并且服务器可以自由地优化处理收集项目页面的处理以及最有效的方式。基本思想是让客户端在 URI 中指定查询以及它想要检索的项目的索引。无需将“页面”的想法推送到资源中，甚至无需使其可见。客户端可以迭代检索对象，直到它的页面已满或收到 404。

当然有一个缺点...... HTTP 服务器和基础设施必须支持流水线，否则创建/破坏连接的成本可能会彻底扼杀这个想法。

于 2009-05-30T15:53:32.937 回答