我正在为系统中的某些资源设计 REST API。 系统允许用户上传文件。
有 3 种资源：
- 发布/获取文件(数据文件(。 获取配置文件(
- 文件格式的元文件(格式是系统特定的 - 比如我的系统中的 CSV 文件应该如何，Json 文件应该如何等(。
- 获取服务器资源和权限的配置文件。
我正在考虑该形式的一些网址：
host/api/v1/files.host/api/v1/config/files.host/api/v1/config/server.
host/api/v1/config/files，host/api/v1/config/server更有意义或host/api/v1/files/config，host/api/v1/server/config更有意义吗？
此外，当datafiles的config版本更改为v2时，将服务器配置文件的版本也更改为v2是否有意义 - 尽管它们是不相关的并且不会一起更改？
或者我可以将文件和文件配置大致分类为同一类别/host/api/files/v1/data/host/api/files/v1/config
和另一个类别中的服务器配置为/host/api/server/v1/config
然后两者都可以独立更改，而无需server/v1/config迁移到v2。
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( 属性(，它可能声称展示;因此，如果接口到 服务以非向后兼容的方式更改，它不再 表示原始服务的实例，但更像是一个 全新的服务。