使用内部锚点来过滤 REST API 的表示是否有意义？
作为我之前关于检索 REST URI 的问题的后续内容网络论坛资源的统计信息，我想知道是否可以使用内部锚点作为过滤器提示。请参阅下面的示例：
a) 获取所有统计信息：
GET /group/5t7yu8i9io0op/stat
{
group_id: "5t7yu8i9io0op",
top_ranking_users: {
[ { user: "george", posts: 789, rank: 1 },
{ user: "joel", posts: 560, rank: 2 } ...]
},
popular_topics: {
[ ... ]
},
new_topics: {
[ ... ]
}
}
b) 仅获取热门主题
GET /group/5t7yu8i9io0op/stat#popular_topics
{
group_id: "5t7yu8i9io0op",
popular_topics: {
[ ... ]
}
}
c) 仅获取排名靠前的用户
GET /group/5t7yu8i9io0op/stat#top_ranking_users
{
group_id: "5t7yu8i9io0op",
top_ranking_users: {
[ { user: "george", posts: 789, rank: 1 },
{ user: "joel", posts: 560, rank: 2 } ...]
}
}
或者我应该使用查询参数吗？
As a follow up to my previous question about REST URIs for retrieving statistical information for a web forum Resource, I want to know if it is possible to use the internal anchors as filter hints. See example below:
a) Get all statistics:
GET /group/5t7yu8i9io0op/stat
{
group_id: "5t7yu8i9io0op",
top_ranking_users: {
[ { user: "george", posts: 789, rank: 1 },
{ user: "joel", posts: 560, rank: 2 } ...]
},
popular_topics: {
[ ... ]
},
new_topics: {
[ ... ]
}
}
b) GET only popular topics
GET /group/5t7yu8i9io0op/stat#popular_topics
{
group_id: "5t7yu8i9io0op",
popular_topics: {
[ ... ]
}
}
c) GET only top ranking users
GET /group/5t7yu8i9io0op/stat#top_ranking_users
{
group_id: "5t7yu8i9io0op",
top_ranking_users: {
[ { user: "george", posts: 789, rank: 1 },
{ user: "joel", posts: 560, rank: 2 } ...]
}
}
Or should I be using query parameters ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不确定您到底想做什么，但请确保您了解服务器看不到片段标识符，它们被客户端连接器截断。
请参阅：http://www.nordsc.com/blog/?p=17
Not sure what you are trying to do exactly, but make sure you understand that fragment identifiers are not seen by the server, they are chopped off by the client connector.
See: http://www.nordsc.com/blog/?p=17
我从来没有见过锚被这样使用——这很有趣。话虽这么说，我建议使用查询参数有几个原因：
它们是标准的 - 并且您的 api 的使用者会对它们感到满意。没有什么比处理古怪的 api 更烦人的了。
许多框架将自动解析查询参数并将它们设置在请求对象的字典中（或框架/http服务器库中存在的任何类似物）。
I've never seen anchors being used that way - it's interesting. That being said, I'd suggest using query parameters for a couple of reasons:
They're standard - and consumers of your api will be comfortable with them. There's nothing more annoying that dealing with a quirky api.
Many frameworks will auto-parse the query parameters and set them in a dictionary on the request object (or whatever analogue exists in your framework / http server library).
我认为这样更有意义：
I think it would make more sense to have:
不，你不能这样做，因为正如 Jan 指出的那样，服务器永远不会看到该片段标识符。从字面上看，该部分 url 将不会到达服务器。
No you cannot do that because as Jan points out the server will never see that fragment identifier. Literally, that part of the url will not reach the server.