Question

让我们说我有三个相关的资源：

Grandparent (collection) -> Parent (collection) -> and Child (collection)

以上描述了这些资源之间的关系：每个祖父母都可以映射到一个或几个父母。每个父母可以映射到一个或多个孩子。我希望能够支持使用过滤条件搜索子资源：

如果我的客户通过了我对祖父母的id引用，我只想搜查那个祖父母的直系后代的孩子。

如果我的客户向我传递了父母的id引用，我只想搜索与我父母直接相关的子女。

我想到了这样的事情：

GET /myservice/api/v1/grandparents/{grandparentID}/parents/children?search={text}

和

GET /myservice/api/v1/parents/{parentID}/children?search={text}

分别满足上述要求。

但我也可以这样做：

GET /myservice/api/v1/children?search={text}&grandparentID={id}&parentID=${id}

在这个设计中，我可以允许我的客户端在查询字符串中传递一个或另一个：grandparentID或parentID，但不能同时传递两者。

我的问题是：

1）哪种API设计更加RESTful，为什么？在语义上，它们的意思和行为方式相同。 URI中的最后一个资源是＆＃34; children＆＃34;，实际上暗示客户端正在子资源上运行。

2）从客户的角度来看，每个人在可理解性方面的优缺点是什么，以及从设计师的角度来看可维护性。

3）什么是查询字符串真正用于，除了＆＃34;过滤＆＃34;在你的资源？如果使用第一种方法，filter参数将作为路径参数而不是查询字符串参数嵌入URI本身。

谢谢！

Answer 1

需要注意的是，因为您在上面的示例中使用了GET，取决于最终用户浏览器设置，代理设置或其他调用应用程序内部设置，响应可能会缓存在消息路由的某个位置，原始请求消息可能永远不会实际到达访问最新数据的API层。首先，您可能想要查看使用动词GET的要求。如果您希望API每次都返回最新数据，那么不要使用GET，或者如果您仍想使用GET，则要求调用者在URL的末尾附加一个随机数，以减少可能性缓存的引擎盖。或者让客户在每次GET之后发送动词PURGE。

互联网，浏览器和服务器架构中存在的这种代理缓存行为是REST失败的地方，因为GET的缓存可能非常有用，但有时只是。坚持基本的查询字符串，如果你想让最终的开发人员真的很简单，反应的缓存不会给你带来任何问题，要么只是使用POST并忘记这个令人讨厌的REST参数

通过URI和查询字符串设计REST API

1 个答案: