REST：我应该重定向到实体的版本 URL 吗？
我目前正在开发 REST 服务。该服务有一个具有不同版本的实体，类似于维基百科文章。
现在我想知道如果
GET /article/4711
我应该使用（临时）重定向到当前版本，例如
GET /article/4711/version/7
或者我应该直接返回当前版本，我应该返回什么？使用重定向将大大简化 HTTP 缓存（使用 Last-Modified），但也有重定向的缺点（额外的请求，“更难”实现）。因此我不确定这是否是一个好的做法。
有什么建议、建议或经验可以分享吗？
（顺便说一句：曾经尝试过搜索“REST Version”吗？您得到的所有内容都是关于 API 的版本而不是实体。因此，如果这是重复的，请耐心等待。）
I am currently working on a REST service. This service has an entity which has different versions, similar to Wikipedia articles.
Now I'm wondering what I should return if for
GET /article/4711
Should I use a (temporary) redirect to the current version, e.g.
GET /article/4711/version/7
Or should I return the current version directly? Using redirects would considerably simplify HTTP caching (using Last-Modified) but has the disadvantages a redirect has (extra request, 'harder' to implement). Therefore I'm not sure whether this is good practice though.
Any suggestions, advise, or experiences to share?
(btw: ever tried search for "REST Version"? Everything you get is about the version of the API rather than entities. So please bear with me if this is a duplicate.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您将版本视为实体（从外观上看您确实这样做），我建议您这样做：
GET /article/4711返回所有版本的列表（以及指向它们的链接）。这使得
/article/4711成为一个容器实体。GET /article/4711/latest返回最新版本的内容。您可能需要考虑
/version/latest以与以下内容保持一致。GET /article/4711/version/7返回文章的特定版本。
If you treat versions as entities (which by the looks of it you do) this is what I'd suggest:
GET /article/4711returns a list of all versions (and links to them). Which makes
/article/4711a container entity.GET /article/4711/latestreturns contents of the latest version. You might want to consider
/version/latestto get in-line with the below.GET /article/4711/version/7returns the specific version of the article.
取决于您对
GET /article/4711的预期行为。如果它打算始终指向最新版本，那么它应该直接返回最新版本。重定向到特定版本似乎有问题，因为您依赖用户/客户端库将来不再访问该特定 URL。为了翻译成 HTML 术语，用户可能会为version/7URL 添加书签，并惊讶地发现他们现在访问的是旧版本，而不是他们最初在地址栏中输入的最新版本。Depends on your intended behavior for
GET /article/4711. If it is intended to always point to the latest version, then it should return the latest version directly. Redirecting to a particular version seems problematic as you are relying on the user/client library to not visit that particular URL in the future. To translate into HTML terms, a user might bookmark theversion/7URL and be surprised that they are now accessing an older version instead of the up to date version they originally typed into the address bar.您可能需要查看 https://datatracker.ietf。 org/doc/html/draft-brown-versioning-link-relations 。
使用 CMIS 链接关系和 HTTP 链接标头，您可以使 /article/4711 成为最新版本并提供版本链接，例如链接：;rel=version-history
You might want to look at https://datatracker.ietf.org/doc/html/draft-brown-versioning-link-relations .
Using the CMIS link relations and the HTTP Link header you can make /article/4711 the latest and provide a link to the versions, e.g. Link: </article/4711/versions>;rel=version-history
文章版本和超文本
如果您确实关心使界面成为 RESTful，那么您应该考虑如何以 HATEOS 风格来实现这一点。
在我看来，这意味着返回足够的信息，以便用户能够浏览实体的修订列表。如果您从 Roy
那里读到此内容...“不需要发现接口。它是在超文本中定义的。该表示形式告诉客户端如何组成到下一个应用程序状态的所有转换”
...您'您将了解
GET /article/4711应如何返回足够的信息来您会知道什么最适合您的模型，但作为指导，您可以考虑使用标签
......
Article versions and hypertext
If you're really concerned about making the interface RESTful then you should consider how to do this in a HATEOS style.
In my opinion that would mean returning enough information that the user is able to navigate through the list of revisions of your entity. If you read this from Roy ...
"The interface doesn’t need to be discovered. It is defined right there in the hypertext. The representation tells the client how to compose all transitions to the next application state"
... you'll get a feel for how your
GET /article/4711should return enough information toYou'll know what works best for your model but as a pointer you could consider using tags
...
我认为返回以下版本的修订列表会更轻松：
您还可以：
直接返回当前版本。
I think it would be more restful to return a list of the revisions for:
You could also have:
Which returns the current version directly.