我正在設計一個API Rest服務，允許用戶將文件上傳到服務器。我可以在沒有ID的情況下放入嗎？
我在想這是一個PUT請求，它會去服務器/資源/ ID，並在json請求正文中有base64文件。
我的問題是關於這個ID。在我的腦海中，我將文件傳遞給服務器，服務器應該負責存儲該文件並生成一個唯一的ID以便稍後檢索該文件，然後將此ID返回給客戶端，並且狀態爲ok。
所以我正在考慮這樣做，將它發送到服務器/資源，沒有ID，但是這是好的還是壞的設計？
No. PUT的意思是「創建或更新」，並應帶有明確的ID。 POST適用於創建新的東西。
關於這個問題我莫名其妙地與@TatsuyukiIshi給出的接受的答案不同意的實際稱號。 PUT的語義是：將當前在給定URI處可獲得的內容替換爲請求中包含的有效內容。如果可以在沒有ID的情況下識別資源，即只存在其中一種類型的資源，則有可能在不指定ID的情況下處理更新，因爲「單個資源」的ID已經在端點本身中隱含地給出。儘管如此，我不得不承認這種情況很少。
這種情況可能是一個剪貼板資源，您可以隨意放置任意內容並在稍後檢索它。當然，你也可以使用POST，雖然POST請求收到的正文的語義不太清楚。與PUT操作相反，POST也不是冪等的。
然而，使用諸如PUT /api/messages之類的東西通常意味着用請求發送的內容代替所有消息，這可能並不是您真正想要的。通常您只需要一次修改單個資源，因此使用標識特定資源的隨附標識。
關於問題的實際內容，通過POST上傳文件是常見操作。在成功上傳時，您將返回一個201 Created響應，其中包含指向生成的資源的Location HTTP標頭。通過POST收到的請求業務處理內容的行爲是完全以達到服務實現。因此，您可以創建一個新的資源，沒有任何實際的資源創建或其他東西（甚至更新不規範禁止）執行一些任務的支持。
太晚了你，但我有同樣的問題，發現了大量的錯誤信息，所以我會在這裏讓什麼發現。
有2 RFC掌管REST風格的，關於這個問題的一個是RFC 7231中，你會發現：
目標資源的狀態是 創建或替換的PUT方法請求包含在請求消息有效載荷中的表示 定義的狀態。
所以你不能沒有ID發送PUT。
很多RESTful API甚至會在更新時發送POST，這也是錯誤，因此您應該始終使用PUT來發送ID以創建它，或者應該使用POST來創建並更新PUT，但請記住POST應該總是創建，換句話說，如果你不先用GET來查找它，你會複製你的文件。
如果你想創建一個新的形象，你應該使用POST，在這種情況下，服務器將與ID返回對象，所以你是正確的，你不必使用一個ID，但該方法也是錯誤的。 –