這是REST的正確實現嗎？

我一直在穩步構建API的資源，但是經過對構建RESTful API的正確方法進行了大量研究之後，我一直無法找到應該如何接收「複雜」請求的示例。這是REST的正確實現嗎？

例如，作爲登錄過程（這是比的認證密鑰更新更小）的一部分，下面的URI是由客戶端分派：

/api/auth/login

上有URI任何值，則資源是/auth/，正在觸發的命令是/login/。實際的登錄細節被髮送到服務器授權標頭。

現在，什麼促使我問這個問題是因爲我正在編寫一個命令讓客戶得到密鑰有效期限的提醒，我立即被提到getkeyexpiration或類似的命令名稱。

突然間，我覺得這聽起來不像我在6個約束中所讀到的，這種感覺更像操作調用。

因此，基於上面的例子，這仍然是一個RESTful API？我很擔心，因爲我無法想象通過簡單地使用URI資源名稱和附加值來執行此操作的方法。

謝謝

編輯：

從閱讀本：http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http，通過命名與名詞性詞語的資源，只有資源

我開始明白，在服務器將如何運作的背景變成更清晰。

關於我上面的例子：

/api/auth/login

我已經使用身份驗證作爲登錄的前綴，因爲那是資源的上下文。我將我的系統設計爲可擴展的，並需要一種方法來對URI級別的資源進行分類。有沒有這樣做的標準方式？

來源

2012-10-30 Flosculus

您的RESTful資源應該是名詞，因爲HTTP提供了動詞。

我建議這樣的，而不是什麼：

/api/key

然後你就可以POST到（與HTTP授權頭包括）創建一個新的密鑰，返回是這樣的：

/api/key/1234ABCDBLAHBLAH

這是特定於會話的關鍵，然後您可以通過GET來檢索關於它的詳細信息，例如到期時間等。當然，您必須將該密鑰傳遞給每個後續請求。

如果在RESTful API的上下文中討論時關鍵的東西聽起來很笨重，那是因爲它通常是。會話是人類/瀏覽器的概念，但RESTful API是應用程序/集成的概念。

由於服務器沒有「登錄」到其他服務器，這就引出了一個問題：如果您已經確定要求調用者將Auth頭傳遞給您的登錄API，爲什麼不只是要求它被傳遞每個 API調用，並忘記密鑰的概念？

來源

2012-10-31 19:32:00

最後一點，用戶（在這種情況下，系統管理員）需要一個用戶名和密碼，無論它是否是一個安靜的api。它的工作方式是發送用戶名和傳遞一次，服務器用新生成的密鑰更新用戶認證表並將其發回給客戶端，然後客戶端可以使用認證密鑰（直到它到期）。它是避免在每個請求中發送純文本用戶標識和密碼的一種手段。 – Flosculus

客戶端檢查密鑰不是必需的，當密鑰過期時客戶端將知道並且必須重新登錄，這將由客戶端應用程序本身自動完成。 api URI遵循與MVC路由//module/resource/action類似的系統。一個行動可能是一種子資源。我不完全適合使用URI發送數據，因爲我無法確定請求是否可以延長。命名約定是我打破上述例子的唯一限制嗎？ – Flosculus

我已經切換到使用類似於您現在描述的系統，所以謝謝 – Flosculus

這是REST的正確實現嗎？

回答

相關問題