我們有一個 POST API 正在生產中。現在我們需要接受本地化資訊并相應地繼續執行。例如，如果 distanceUnit 是“KM”，則以公里為單位處理所有傳入資料。
我可以想到三個選項來接受本地化資訊。
- 作為 http 標頭，即本地化：{"distanceUnit": "km"}
- 作為有效載荷本身的一部分。
- 請求引數。
我喜歡第一個選項
- 它不會改變 api 合同。
- 其他 api 可以更輕松地發送此資訊，以防將來需要對其進行本地化。
- 本地化是內容協商的一部分，所以我認為它不應該是有效載荷/查詢引數的一部分。
這里的任何意見都有助于在第一個或第二個選項中歸零。
謝謝。
uj5u.com熱心網友回復：
雖然accept-language，如建議的鏈接工具包所示，可能正在嘗試，但這僅支持由 IANA 維護的注冊語言，Web 的標準化 gremium，但不支持某些開箱即用的通用配置選項。它可能試圖默認miles為 ieAccept-Language: us并km在其他地方使用，美國科學家可能會對您的應用程式有某些問題，如果他們想使用km而不是miles. 但如果情況并非如此，這顯然是您可以考慮的一個選項。關于自定義 HTTP 標頭，我不建議使用它們，因為自定義 HTTP 標頭的問題通常是任意通用 HTTP 客戶端不支持這些，這在某種程度上與為什么應該使用 REST 架構的想法相矛盾。
讓我們暫時將您的問題轉移到 Web 域，看看我們通常如何在那里解決該任務。由于 REST 基本上只是我們人類與 Web 互動的常見方式的一種通用方法，因此 Web 上使用的任何概念也適用于 REST 架構。因此，將整個互動流程設計為就好像您的應用程式在典型的 Web 頁面上進行互動只是常見做法（或至少應該如此）。
在 Web 上，所謂的Web 表單用于“教導”Web 客戶端（又名瀏覽器）服務器期望作為輸入的資料。它不僅告訴客戶端服務器期望或支持特定資源的相應屬性，而且還告訴客戶端使用哪種 HTTP 方法，關于將請求發送到的目標 URI 以及要使用的媒體型別，這通常是隱式的只是作為application/x-www-form-urlencoded但也可能是multipart/form-data。
表單和鏈接的使用屬于 HATEOAS 約束，其中這些概念允許客戶完成他們的任務，即在網上商店購買商品或在系統中管理用戶，而無需查閱外部檔案全部。這里的應用程式基本上只是使用內置的超媒體功能來完成他們的任務。客戶端通常遵循某種預定義的流程服務器指示客戶端需要做什么才能將商品添加到購物車或如何添加或編輯用戶，同時仍然只對本身不適合相應任務的通用 HTML 檔案進行操作在手。這種方法允許 Web 客戶端基本上呈現所有型別的頁面，并且用戶可以與這些通用頁面進行互動。如果該頁面表示中的某些內容發生更改，您的瀏覽器將自動適應并在下一個請求時呈現新版本。因此，該系統能夠隨著時間的推移而發展并輕松適應變化。這可能是任何人基本上想要使用 REST 架構的核心原因之一。
那么，回到正題。在 Web 上，服務器會向客戶端通告它支持具有上述形式的各種本地化資訊。用戶可能會看到一個選項或下拉選項，他/她可以在其中選擇適當的選項。用戶通常不關心此輸入如何傳輸到服務器或根本不關心服務器的內部結構。他/她所關心的只是在提交請求后資料是否可用（在添加或更新資源的情況下）。這也適用于 REST 架構中的應用程式。
您可能會在這里看到一個模式。REST 和可瀏覽的 Web 基本上是一回事。后者雖然側重于人機互動，而初級版應該允許應用程式“瀏覽網路”并自動（半）自動地遵循服務器概述的所有程序。因此，現在應該很清楚，適用于可瀏覽 Web 的相同概念也適用于 REST 和該 REST 架構中的應用程式。
我喜歡第一個選項，因為它不會改變 api 合同
客戶端不應該系結到特定的 API，因為這會產生耦合，REST 會不惜一切代價避免這種耦合。與直接系結到 API 不同，Web 和 REST 應該使用建立在超媒體型別上的契約，這些契約定義了所交換訊息的可接受語法和語意。通過將合約從 API 本身抽象為媒體型別，客戶端可以同時支持各種合約。媒體型別的泛化還允許即用相同的媒體型別表達各種不同的東西，從而增加重用的可能性，從而更好地集成到應用程式層中。
支持各種媒體型別類似于說不同的語言。通過能夠說各種語言，您只需增加開箱即用即可與其他人（服務）進行交流的可能性，而無需之前學習這些語言。客戶端可以通過Accept標頭告訴服務器它能夠“說話（（也稱為行程）”的媒體型別，并且服務器將使用這些媒體型別中的任何一個進行回應或以406 Not Acceptable.始終告訴您一切是否順利或出現故障的協調資料可為您提供有關問題的反饋。
為了保持面向未來，我建議圍繞支持表單的超文本媒體型別設計配置，即 HTML 表單、applicaiton/hal-forms json或application/ion json。如果將來您需要添加更多配置選項，添加這些只是一項微不足道的任務。該配置是作為您剛剛鏈接到的自己的資源公開，作為資源中的嵌入部分還是根本不回傳給客戶端也是您的選擇。如果多個資源可以使用相同的配置，那么將其作為自己的資源公開，然后僅創建從資源到該配置的參考將是有益的，但如前所述，這些是您必須做出的設計決策。
uj5u.com熱心網友回復：
如果 POST 請求正文是唯一使用它的地方，并且您永遠不必執行GET請求并自動應用任何轉換，那么我的首選可能是將其添加到正文中。
擁有包含描述自身的所有資訊的完整檔案，而不需要外部帶外資料來完全解釋其含義，這真是太好了。
您可能希望將架構定義為始終在檔案的相關部分中包含該單元，例如：
distance: [5, 'km']
或者，如您所說，在檔案頂部執行一次。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/340209.html
標籤：休息
上一篇：僅反序列化少數屬性
下一篇：與Null安全性的混淆