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屬性）;因此，如果服務的接口以非向後兼容的方式改變，則不再是 代表原始服務的實例，而是相當全新的服務。