創建用戶帳戶時更正HATEOAS響應

Question

我在使用HATEOAS的節點中寫入REST api。用戶必須擁有一個帳戶才能訪問其中的大部分內容。

他們註冊一個包含登錄詳細信息的帳戶，然後登錄以獲取訪問令牌，然後使用該令牌訪問任何不是register或login的端點。

向根發出get響應帶有可用操作的目錄。

問：來自register的正確答案是什麼，告訴客戶接下來可以做什麼（即登錄）？

1. register技術上創建服務器所以201 CREATED和Location頭似乎appopriate上一個新的資源。但login引用不是新創建的資源的位置。

2. 我應該用Location指向返回201 Created到新創建的用戶（例如/myaccount或/users/{id}，然後在響應中包含主體中的登錄鏈接？

 
    { 
     _links: { 
      self: { href: "what goes here?" }, 
      x:login: { href: "/login" } 
     } 
    } 

我是否根本不告訴客戶端，並要求他們在應用程序根目錄上執行get以獲取可用端點列表，其中應該包括login，假設客戶端必須首先執行此操作得到register鏈接它應該已經有login。

期待客戶​​已經擁有登錄鏈接的感覺不舒服，因爲它依賴於客戶以前的活動假設。

要求客戶端在註冊後向根目錄發出另一個請求似乎意味着低效和不必要。如果客戶剛剛創建了一個資源，那麼服務器應該用它接下來的工作做出迴應似乎是公平的。

Answer 1

我喜歡讓我的api的行爲與網頁沒有區別。如果您希望您的應用程序的UX用戶在註冊後被註冊登錄，請將其從成功註冊的用戶登錄到登錄資源。並且在成功登錄時，302將它們移動到適當的目的地（IE，如果他們試圖訪問沒有令牌的東西，則帶着它們登錄，並具有原始請求資源的目的地）。這對你的＃3是重要的一部分。關閉導致登錄的根的鏈接，但需要保護所有其他鏈接，以便它們指示（並鏈接到）訪問資源所需的登錄名。客戶端應用程序應隨時獲得此登錄所需的響應，因爲令牌隨時可以（並且會）到期。

在此之後，將JWT作爲一個cookie而不是Authorization Header可能是有意義的，它會使客戶端更容易一些（他們只需要設置一個cookie jar）。如果客戶端說是一個原生的移動應用程序，保持單一的連接設置。如果它是服務器到服務器，那麼auth頭是有道理的。我會去支持這兩種情況。

繼續思考api作爲一個網站的想法。爲什麼他們在註冊後一直登錄？爲什麼不註冊一個帳戶最終會發送登錄令牌？他們只是設置他們的用戶/密碼，爲什麼讓他們再次輸入？我意識到一些更具異國情調的體系結構註冊服務不能執行登錄操作（也許它沒有私鑰來簽署令牌），但如果可能的話我會考慮它。

如果你真的想堅持201頭（這很好，只要確保你的註冊關係的文檔指出），然後選項2是最接近我的意見。剛剛創建的帳戶的URL的位置標題爲201是用於創建用戶的非常標準。但是，我不會返回你在那裏的。你有種回報帳戶創建的資源（與登錄鏈接的東西），但你真的需要這個自定義資源？如果您想在該資源中向客戶端發送一些消息（如「創建帳戶」），那麼肯定是，但您也可以將它們還給根資源。

tl; dr;決定你希望你的UX是什麼，然後讓你的API實現你的UX。