是否有關于由 REST 服務器重新調整的位置是否還應包含版本資訊的標準或約定？根據 REST，URI 指向資源，因此根據該定義，Location標頭中回傳的 URI 不應具有版本。
但是GET服務器回傳的位置上的 a 應該可以作業，但是如果沒有將版本資訊添加到 URI，它就會失敗。客戶端是否應該知道服務器的首選版本，尤其是當可能存在聚合不同 API 版本上的多個后端微服務的 API 網關時？
是否有這方面的標準，服務器是否應該在回應中回傳 API 版本？
uj5u.com熱心網友回復：
在版本控制和 REST方面沒有標準。REST 是一個約束系統。但是，有一些版本控制方法符合約束，也有一些不符合約束（例如在 URL 路徑中）。
不應將 API 版本視為與二進制檔案版本相同的方式。雖然“API 版本”是一個被廣泛接受的術語，但它有點用詞不當。API 版本不指示為 API 呼叫哪種方法，它指示格式。請記住，HTTP是API。HTTP 沒有方法多載或版本。這背后是一個實作細節。
這意味著媒體型別最好地描述和服務于 API 版本的目的，即使有其他方式來傳達它。Location服務器的作業是在您使用服務器生成的識別符號創建資源時告訴您資源的位置。沒有義務告訴您（客戶端）希望它采用什么格式。由于您剛剛創建了一個指定特定 API 版本（或格式）的資源，因此您應該知道如何發送一個GET來檢索該資源。
相同的規則和邏輯適用于 HATEOAS。如果服務器提供相關資源的位置，它就無法知道您（客戶端）想要的那些資源的 API 版本（或格式）。服務的獨立演進通常會導致跨 API 的異構版本。
這些概念究竟如何應用于微服務有點離題，但完全有可能一個服務以某種v1格式寫入資源，而另一個服務以一種v2或v3格式讀取資源。無論如何，Location資源應該是相同的，并且可以跨服務邊界共享。
uj5u.com熱心網友回復：
根據 REST，URI 指向資源，因此根據該定義，Location 標頭中回傳的 URI 不應具有版本。
這并不完全符合。
URI 是資源識別符號；它標識了一種資源，其中“任何可以命名的資訊都可以是一種資源（Fielding，2000）。
一般來說，資源的表示是時間的函式；并且對 GET 請求的回應預計會回傳該資源的最新版本。
但是，如果這不合適，那么可以改為對具有不是時間函式的表示的不同資源進行建模。
/705604c9-2e1f-43c8-953e-7659f44f5b32 <-- "version 0"
/bbd02ea3-96d8-41dd-ac70-4748bd3e93ac <-- "version 1"
/86d09182-5002-4568-8a4a-352a75daa40c <-- "version 2"
/32a856ef-4894-49f4-8e27-ab3ab41de71f <-- "latest"
當然，這些識別符號對于試圖識別它們的人來說并不是特別有幫助，因此您可能希望使用更友好的拼寫約定
/foo/history/0
/foo/history/1
/foo/history/2
/foo
對于API版本，您的人類可能會對路徑段的不同優先級更滿意
/api/v0/foo
/api/v1/foo
/api/v2/foo
/api/foo
在向后兼容性很重要的背景關系中，您需要非常小心地更改資源的含義。
在含義不變但表示隨時間變化的情況下，您可以使用內容協商（主動或被動）來幫助客戶端檢索具有正確模式的表示。因此，如果有人嘗試獲取資源，但沒有在 Content-Type 標頭中描述您支持的架構之一，那么您可能會向他們發送300 Multiple Choices回應，然后從那里開始。
（此時，我們開始進入定制客戶端領域，這有點超出 REST 的范圍，它本身專注于通用組件。）
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/418645.html
標籤：