REST 版本控制 - URL 与标头 [英] REST versioning - URL vs. header
问题描述
我打算编写一个 RESTful API，但我对如何处理版本控制一无所知.我已经阅读了许多讨论和博客文章，其中建议使用 accept 标头进行版本控制.
I am planning to write a RESTful API and I am clueless how to handle versioning. I have read many discussions and blog articles, which suggest to use the accept header for versioning.
但后来我发现以下网站正在侦听流行的 REST API 及其版本控制方法，其中大多数使用 URL 进行版本控制.为什么?
But then I found following website listening popular REST APIs and their versioning method and most of them using the URL for versioning. Why?
为什么大多数人说:不要使用 URL，而是使用 accept 标头"，但使用 URL 的流行 API?
Why are most people saying: "Don't use the URL, but use the accept header", but popular APIs using URL?
推荐答案
这两种机制都是有效的.您需要了解您的消费者才能知道该走哪条路.一般来说，与企业和有学术头脑的人合作往往会将开发人员指向资源头版本控制.但是，如果您的客户是小型企业，则更广泛地使用 URL 版本控制方法.
Both mechanisms are valid. You need to know your consumer to know which path to follow. In general, working with enterprises and academically-minded folks tends to point developers towards Resource Header versioning. However, if your clients are smaller businesses, then URL versioning approach is more widely used.
优点和缺点(我相信还有更多，其中一些缺点具有此处未提及的变通方法)
它更具探索性.对于大多数请求，您可以只使用浏览器，而 Resource Header 实现需要更程序化的测试方法.但是，因为并非所有 HTTP 请求都是可探索的，例如 POST 请求，您应该使用像 Postman 或 Paw.URI Pro/Header Con
使用 URI 版本化 API，资源标识和资源的表示被混合在一起.这违反了 REST 的基本原则；一种资源应由一个且仅一个端点标识.在这方面，Resource Header 版本控制选择在学术上更加理想化.Header Pro/URI Con.
With a URI-versioned API, resource identification and the resource’s representation is munged together. This violates the basic principles of REST; one resource should be identified by one and only one endpoint. In this regard, the Resource Header versioning choice is more academically idealistic. Header Pro/URI Con.
如果您想进一步阅读，这里有一些有用的链接:
这篇关于REST 版本控制 - URL 与标头的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
