在什么情况下我应该将客户端重定向到更准确的 URI
我们有一个 RESTFul Web 服务，可以返回人员列表。
/person/list
但是，企业希望仅返回“活跃”人员。即 2009 年之后创建的人员。
我建议将 (307?) /person/list 重定向到 /person/list?createdAfter=2009，因为这是资源的更准确表示。有道理吗？如果没有，为什么不呢？
We have a RESTFul webservice that returns a list of persons.
/person/list
However, the business wants to return only "active" persons. i.e. persons created after 2009.
I'm proposing to redirect(307?) /person/list to /person/list?createdAfter=2009 since that is a more accurate representation of the resource. Does it make sense? If not, why not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我看来，URL /person/list 应该返回一个未经过滤的列表。要获取过滤列表，您应该显式指定 createAfter=2009。
我说这个想法是为了以后的事情。如果您的应用程序实际上需要所有用户怎么办？如果您有一堆依赖 /person/list 的旧代码神奇地重定向到过滤后的版本，并且出于某种原因需要将 URL /person/list 更改为实际上未过滤的版本，该怎么办？然后你的旧代码就崩溃了，因为它会拉动所有用户。
我会采用两种方法之一：
1）不重定向。只需让 /person/list 默默地暗示只有活跃的人。在这种情况下，要获得非活动状态，您必须实际请求 /person/list?all 或 /person/list?includeInactive 或其他内容（希望您明白这一点 - 您必须明确请求禁用的）
2）实际上在您的应用程序中使用带有 ?createAfter=2009 的 URL。
我可能会选择第一个选项。它可以让您在 Web 服务中而不是在应用程序中保留活跃人员的逻辑，这意味着 URL 的含义永远不会改变（只是 /person/list 会被理解为仅包含以下内容的列表）活跃的人）。
In my opinion, the URL /person/list should return an unfiltered list. To get the filtered list, you should have to explicitly specify createAfter=2009.
I say this thinking of down the road. What if you have an application that does actually want all of the users? What if you have a bunch of old code depending on /person/list magically redirecting to the filtered version and you for some reason need to change the URL /person/list to actually be the unfiltered version? Then your old code just broke because it would be pulling all users.
I would go with 1 of two approaches:
1) Do not redirect. Just have /person/list silently imply only active persons. In this situation, to get the non active, you would have to actually request /person/list?all or /person/list?includingInactive or something (hopefully you get the point -- you have to explicitly request the disabled ones)
2) Actually use the URL with ?createAfter=2009 in your applications.
I would probably go with the first option. It lets you keep the logic of what an active person is and isn't in your webservice instead of in applications, and it means the meaning of the URL will never change (just /person/list would be understood to be a list of only active persons).
使用 /person/list/active 有什么问题？您知道“活跃”一词是在 2009 年之后创建的，但定义可能会发生变化。
What's wrong with using /person/list/active? You know that active is created after 2009 but the definition could change.