リソースが存在しない場合、HTTP PUTはリソースを作成する必要がありますか？
私のエンドイントで誰かがPUTリクエストを実行するとします：
/resources/{id}
ただし、PostgreSQLデータベースに指定されたIDのリソースが保存されていません。
RFC 2616 によると、次のことができる場合はリソースを作成する必要があります。
PUTメソッドは、囲まれたエンティティが指定されたRequest-URIの下に格納されることを要求します。 Request-URIが既存のリソースを参照している場合、囲まれたエンティティは、Originサーバーにあるエンティティの変更バージョンと見なされるべきです（SHOULD）。 Request-URIが既存のリソースをポイントせず、そのURIが要求元のユーザーエージェントによって新しいリソースとして定義できる場合、オリジンサーバーはそのURIでリソースを作成できます。
指定されたIDでリソースを作成してもよろしいですか？データベース挿入時に手動でIDを割り当てることはベストプラクティスではないため。
404リソースの作成が不可能な場合のエラー？
つまり、格納するペイロードがサーバーがリソースに対して課している制約に違反しているかどうかによって異なります。
一般的には、クライアントがターゲットURIにその特定の表現を格納する意図を明示的に表明しているため、試行する必要があると思います。ただし、サーバーは前に制約チェックを実行する必要があります。通常、実際のREST=シナリオでも、クライアントはサーバーが提供するURIを使用する必要があり、それ自体でURIを選択するだけではありません。これにより、サーバーは名前空間を制御する必要があります。したがって、PUTを使用してリソースを作成することは、デフォルトでは推奨されません。
そうは言っても、PUTはべき等ではないのに対しPOSTはべき等ではないので、一部のクライアントはこのプロパティの恩恵を受けたいと思うかもしれません。ここでは POST-PUT作成パターン が進化し、クライアントはPOSTヘッダーを介して確認を受け取るまで、Locationを介して新しいリソースを作成しようとしています。応答し、その後PUTを介してそのリソースの状態の更新を試みます。このようにして、クライアントは、伝送の問題が発生した場合に表現が一度だけ作成されたことを確認できます。スタンスによっては、リソースの実際の更新を実際のリソースの作成と見なす人もいますが、クライアントが事前にそれぞれのリンクを受け取っているため、これは完全には当てはまりません。
サーバーが特定のURIエンドポイントに特定の表現を提供するように構成されている場合、サーバーには表現を別の表現に変換する権利もあることに注意してください。 PUTを介して画像をURIにアップロードすると、サーバーは画像をHTMLページに埋め込みます。