設計一個REST風格的網站

Question

我正在嘗試學習如何創建REST風格的Web應用程序。我有一些疑問。

1. 說，我有一個要求在網站標題上顯示用戶的名稱。我曾經這樣做，通過將用戶對象存儲在會話中，然後在JSP中獲取該名稱。但現在，是不是存儲會話數據並違反REST約定？只要用戶登錄（過度使用），我是否必須在每次響應中將名稱發送給客戶端？
2. 我看過很多網站的網址，其中包括模式爲questions/4135336/correct-rest-uri-design的SO。不會questions/4135336就夠了，假設4135336是ID？那之後是什麼？另一個ID？任何標準來生成它？
3. 我讀過一個特定的資源，說/學生/ {學生} CRUD操作應該使用GET（fetch），POST（更新），PUT（創建/覆蓋），DELETE（刪除）來完成。如果它的應用程序被人讀過，我們是否需要這些約定。例如：不會通過發送適當的參數來進行刪除嗎？我們想要實現什麼？

感謝提前:)

Answer 1

REST背後的想法是每個請求都完全獨立於服務器的任何其他角度。客戶負責維護狀態，如果有的話。對於給定的請求，服務器將信息傳輸到滿足該請求所需的客戶端，並且還可以傳輸允許客戶端通過發出更多請求來查找附加信息的信息。有鑑於此：

1. 這種取決於您的網站的設計，以及什麼被認爲是「資源」。如果客戶端請求一個頁面，並且該頁面被視爲單個資源單元，那麼是的，服務器需要返回用戶名作爲任何請求的響應的一部分。如果設計是這樣的，客戶可以要求分片的東西，那麼客戶有責任在請求中詢問用戶名，然後將其呈現在標題中。頁面的其餘部分的內容將以額外的單獨請求呈現。
2. ID已足夠。 URL的其餘部分僅用於人類的可讀性，因爲人類不會輕易記住「415336」是標題爲「正確休息Uri設計」的文章的ID。 URL中的這些額外信息不被服務器用來查找該項目;只有ID被使用。因此，它本身並不是REST的一部分，它只是由網站提供的一種很好的方式。
3. REST理論上應該是客戶端不可知論者;從理論上講，你可以編寫一個通用的REST客戶端，它可以導航任何支持REST的服務器，並且客戶端將能夠發現服務器上的資源並且能夠操縱它們。這是可能的，因爲正如您所指出的，REST利用HTTP動詞的標準詞彙表來表示常見的CRUD操作。如果您將HTTP動詞重載爲其他內容，那麼通用客戶端可能無法導航該網站。此外，如果您重載GET以產生副作用，例如更新或刪除信息，那麼通用客戶端（認爲是網絡爬蟲）最終可能會通過試圖找出網站上可用的內容來破壞信息。這絕不是一個好主意。

Answer 2

針對3號：經驗法則說，你應該用GET與POST目前的數據和處理數據。這樣創建和刪除不需要是POST以外的其他任何東西。

千萬不要使用GET操作數據，否則您的鏈接（somesite.com/users/delete?user=1）可能變成索引並且您的整個數據庫將變得混亂。使用GET來呈現數據還允許用戶爲特定結果添加書籤並提供發送給其他人的鏈接。

Answer 3

對於數字3，你問我們試圖通過使用http方法（最通用的除外）實現什麼。我們實現的是優化潛力。

最通用的方法是POST。後可以做任何事情，包括檢索只讀內容。爲了優化，我們創建了GET。 GET結果可以被高速緩存，因爲每個人都是相同的，並且多個GET請求總是給出相同的結果（對於靜態文件，服務器必須告訴高速緩存有效的非靜態文件）。

我們可以進一步梳理出可以優化的其他用例，例如，如果要刪除特定對象，請使用DELETE方法。如果服務器沒有響應，您可以再次嘗試，而不用擔心，因爲如果對象不見了，您的請求可以被忽略，並且如果對象第一次沒有被刪除，它將在第二次嘗試。如果刪除請求被封裝在通用信封中，客戶端不知道語義（如HTML表單），則無法知道該信息。