Rest URL中的URL版本的URL与相关资源或所有API相同

Question

我正在为系统中的某些资源设计REST API。 系统允许用户上传文件。

有3种资源：

1. 邮政/获取文件（数据文件）。
2. 获取配置文件（文件格式的元文件（格式为特定的系统 - 就像在我的系统CSV文件应该如何，JSON文件应该如何等）
3. 获取服务器资源的configfiles和权限

。

我想到了形式的一些网址：

1. host/api/v1/files
2. host/api/v1/config/files
3. 。。

是否host/api/v1/config/files，host/api/v1/config/server 更有意义或host/api/v1/files/config，host/api/v1/server/config 更有意义？

而且当的datafiles变化v2config版本是否有意义还改变服务器配置文件版本v2 - 尽管是他们无关，不一起改变的事实？

或者我可以大致另一类为 /host/api/server/v1/config

分类下的同一类别的文件的文件和配置作为 /host/api/files/v1/data /host/api/files/v1/config

和服务器配置然后，两个可以独立改变，不需要迁移server/v1/config到v2。

Answer 1

host/api/v1/config/files，host/api/v1/config/server更有意义或host/api/v1/files/config，host/api/v1/server/config使更有意义？

后者。考虑在未来扩展服务，如果例如你想添加一个获取/添加服务器用户的方法。它的网址应该是host/api/v1/server/config。

关于版本控制，服务应作为一个整体来观察。如果您将一部分更新为新版本，则整个服务将转至新版本。如果某些部分完全独立，请考虑制作两项服务。

IBM规定如下：

可以说的是，当在一个 非向后兼容的方式改变服务的接口，在现实中一个全新的服务 被创建。在这种情况下，除非第一个接口的实现继续存在，否则预先存在的服务实际上停止使用 。从客户的角度来看，服务不会超过它可能宣称展示的接口和一些非功能性质量（如信任和QoS属性）;因此，如果服务的接口以非向后兼容的方式改变，则不再是 代表原始服务的实例，而是相当全新的服务。