假設系統管理用戶。用戶通過以下URL公開 - /users。一個特定用戶通過以下網址公開 - /users/{id}。用戶通過以下URL顯示報告 - /users/{id}/reports。不創建資源的POST
一個操作包括生成報告。在/users/{id}/reports上適當的HTTP請求是POST。但是，在某些情況下，生成的報告與上次生成的報告完全相同。因此，我認爲在這種情況下返回最後生成的報告是一種好方法。
我也知道在這種情況下，不會創建任何資源。
是否有正確的RESTful方式來處理這種情況？也許返回一個特殊的代碼？
我會使用304未修改的情況下報告沒有修改。這應該告訴大家，自上次導出後資源並未發生變化，通常也不會傳輸更多內容。這也可以用來代替舊的結果，如果你緩存這些結果。一般來說，304不是用於文章的，但是使用帖子來判斷觸發日誌的創建可能也被認爲有點異乎尋常。
如果客戶端執行了條件GET請求並且允許訪問，但文檔沒有被修改，服務器應該用這個狀態碼進行響應。 304響應不能包含消息體，因此總是由頭字段後的第一個空行終止。
RFC containing explanation of the 304 Status Code
如果創建工作，我會送創造了201和使用位置標頭，如指向新的文件。
是否有正確的RESTful方式來處理這種情況？也許返回一個特殊的代碼？
退一步了一會兒：處理「創造」的用例完全直接的方式看起來像
新資源已被創建的指示是狀態碼：201。 新創建的資源的位置由Location響應報頭中描述。 內容的位置由Content-Location響應頭 描述的當前表示是響應（沒有驚奇）的message body。
HTTP/1.1 201 Created
Location: /users/1/reports/a
Content-Location: /users/1/reports/a
...
<representation of the report goes here>
在你的情況下，如果資源已經存在，那麼事情看起來幾乎相同。爲了避免暗示我們已經創建了新的資源，狀態碼更改爲200，並且位置標題被刪除。
HTTP/1.1 200 OK
Content-Location: /users/1/reports/a
...
<representation of the report goes here>
如果您希望在客戶端使用先前生成的報告的標識符檢索報告表示，那麼你應該使用303 See Other
它主要用來允許POST操作的輸出將用戶代理重定向到選定的資源，因爲這樣做可以提供與POST響應相對應的信息，其格式可以獨立於原始請求單獨標識，加書籤和高速緩存。
HTTP/1.1 303 See Other
Location: /users/1/reports/a
...
此模式通常被稱爲Post/Redirect/Get
304是不恰當的在這裏。請參閱：https：//tools.ietf.org/html/rfc7232#section-4.1 – VoiceOfUnreason