私はユーザーがファイルをサーバーにアップロードできるAPI Restサービスを設計しています。IDなしでPUTできますか？
私はこれがPUTリクエストだと思っており、それはserver/resource/IDに行き、ファイルをjsonリクエストボディにbase64として持っています。
私の質問はこのIDに関するものです。私の頭では、ファイルをサーバーに渡しています。サーバーはそのファイルを保管し、後で取り出すために一意のIDを生成し、このIDをok状態でクライアントに返します。
だから私は、IDなしでサーバー/リソースに送信することを考えていますが、これは大丈夫ですか、それとも悪い設計ですか？
No.は、「作成または更新」を意味し、明示的なIDが付いている必要があります。 POSTは新しいものを作成するのに適しています。
も参照してください：PUT vs POST in REST
私は何とか@TatsuyukiIshiによって与えられた受け入れ答えに反対質問の実際のタイトルについて。 PUTのセマンティクスは次のとおりです。指定されたURIで現在取得可能なコンテンツを、要求に含まれるペイロードに置き換えます。 IDなしでリソースを識別することができる場合、すなわちその種別の1つしか存在しない場合、「シングルトンリソース」のIDが既にエンドポイント自体に暗黙的に与えられているため、IDを指定せずに更新をアドレス指定することが可能である。しかし、私はこれがまれであることを認めなければならない。
このようなケースは、任意のコンテンツを配置して後で取得できるようなクリップボードのようなリソースです。確かに、POSTリクエストで受信したボディのセマンティクスはあまり明確ではありませんが、POSTも使用できます。またPOSTは、PUTオペレーションとは反対に等価ではありません。
しかし、PUT /api/messagesのようなものを使用すると、通常、すべてのメッセージをリクエストと一緒に送信されたコンテンツに置き換えてしまうことになります。通常、一度に1つのリソースを変更するだけで、その特定のリソースを識別する付随するIDを使用します。
質問の実際の内容に関しては、POSTでファイルをアップロードするのが一般的です。アップロードが成功すると、Location HTTPヘッダーが生成されたリソースを指している201 Created応答が返されます。 POST要求を介して受信されたサービス処理コンテンツの動作は、サービス実装者まで合計である。したがって、新しいリソースを作成したり、実際のリソース作成や何か他の何らかのバッキングタスクを実行したりすることができます（更新が仕様によって禁止されていない場合でも）。
あなたにはまだ時間がかかりましたが、私はこの同じ質問をしていましたが間違った情報がたくさんありました。
RESTfulな規則2 RFCがありますが、この質問について1はRFC 7231で、その中にあなたが見つける：
をPUTメソッドは、ターゲット・リソースの状態が 作成したりして交換することを要求します要求メッセージのペイロードに囲まれた表現 によって定義される状態。
したがって、IDなしでPUTを送信することはできません。
多くのRESTful APIは、更新時にもPOSTを送信します。その同じRFCでも間違っていますので、IDを送信してPUTで作成するか、POSTを使用して更新して更新する必要がありますPOSTは常に作成する必要があります。つまり、GETで最初に探していない場合は、ファイルを複製します。あなたは正しいですので、サーバは、IDを持つオブジェクトを返します。その場合にはhttps://tools.ietf.org/html/rfc7231#section-4.3.3
新しいイメージを作成する場合は、POSTを使用する必要がありますが、あなたがする必要はありません。詳細については
IDを使用しますが、方法も間違っています。 –