我們的應用程序對每個用戶都有不同的角色，只有某些用戶被允許查詢數據。我們必須爲每個請求驗證用戶標識和密碼。REST get如何在每個請求中傳遞用戶標識和密碼
我有一個簡單的REST獲取用戶傳遞員工ID並返回員工數據的地方。傳遞用戶名和密碼的最佳方式是什麼？在URL中使用userid和密碼（即@PathParam）不好主意？
現在我有如下，這將由用戶U1返回EMP ID 111僱員數據
的https：../ MyRestWebService /服務/ getEmp/U1/encpassword/111
只有HTTPS端口將在防火牆中打開即所有的請求總是通過https和密碼總是編碼字符串（我們發佈如何編碼）
感謝
這是否是一個好主意總是取決於你如何使用它。至少傳遞密碼本身可能會引起人們的注意，這可能是一個嚴重的問題。
通常，這兩種方法在發出進一步調用之前需要登錄，這模擬了人類用戶使用系統的情況，但需要邏輯來處理客戶端登錄和登出。其次是使用API令牌，這可能不太安全，但對於自動化客戶端更方便。請注意，沒有根本的理由，你不能這樣做。
看看github如何處理API認證;他們實際上都做。您可以執行OpenAuth身份驗證來創建經過身份驗證的會話，該會話採用後續請求中使用的臨時訪問令牌的形式。您也可以創建一個永久訪問令牌並將其關聯到該帳戶。
你也可以使用一個框架或內置了對會議的支持（根據您的服務器堆棧上）隱式跟蹤驗證的會話。
感謝您的詳細解答。客戶端將由我們的Web服務的用戶編寫，他們想要非常簡單的解決方案，添加這樣的內容會增加他們的工作量。用戶名和密碼已經分配好了，所以他們擁有它。我將使用帶有json輸入的post方法，該方法將使用userid，password和emp id。 – user3453204
是，將用戶名和密碼的URI是一個壞主意。對於初學者來說，這意味着你不能在不公開你的用戶名和密碼的情況下共享URI。有沒有一些令人信服的理由你沒有使用HTTP基本認證？這看起來就像它設計的確切情況。
GET https://.../employees/111
是一個更爲正確的URI。
感謝您回答我的問題。我是新來的stackoverflow，它似乎讓我只挑一個正確的答案。 – user3453204
當你說密碼是'編碼'，你可以更具體嗎？ – zanerock
它不會被人類讀取，按規範編碼，例如base64編碼。請注意，所有通信都將通過https和系統管理員來查看tcpdump，或者任何此類跟蹤都將具有對系統的完全訪問權限，包括能夠更改用戶權限，密碼等。即服務器上密碼的安全性不是問題。我從客戶的角度考慮更多。 – user3453204
我更想知道密碼是（公鑰/私鑰）加密的。這聽起來像是「不」，所以任何獲取URL的人都可以解密密碼。 – zanerock