自動増分キーにPUTではなくPOSTを使用するか、リソースIDに自動インクリメントキーを使用しないことをお勧めします。
POSTを使用すると、/users/1ではなく/usersにPOSTされます。返信によって、/users/1またはIDが何であれリダイレクトされる可能性があります。
PUTを使用する場合は、/users/10292829にPUTすることができます。この数字は、クライアントで生成される固有のリソースキーです。このキーは時間を生成することも、時間、セッションID、その他の要因のハッシュを使用して、クライアントのオーディエンス全体で価値の一意性を保証することもできます。サーバーは、10292829またはそれとは別の独自の自動増分インデックスを生成できます。それの詳細について
、フォローアップPUT vs POST in REST
を参照してください。 。 。
すべてのユーザーに対して/ users/XXXXXXXにPUTを許可する場合、同じリソースを参照する2つの異なる固有のキーで終わることになります。 （10292829と1は同じユーザーを参照する可能性があります）。これらの異なるキーをそれぞれREST形式のURLで使用する方法を決定する必要があります。これら2つの異なるIDの使用を調整する必要があるため、最初のオプションである/usersに投稿し、作成されたリソースの固有のREST URLをレスポンスに取得することをお勧めします。
私はちょうどthe relevant section of RFC 2616を再読み込み、具体的には、RESTアプリケーションでは、このために設計されたリターンコードを見た：新しいリソースに
を作成し
10.2.2 201要求が満たされたが、得られました作成されます。新しく作成されたリソースは、レスポンスのエンティティで返されたURIによって参照され、Locationヘッダーフィールドで指定されたリソースの最も特定されたURIが使用されます。レスポンスは、ユーザまたはユーザエージェントが最も適切なものを選ぶことができるリソースの特性および場所のリストを含むエンティティを含むべきである（SHOULD）。エンティティフォーマットは、Content-Typeヘッダーフィールドで指定されたメディアタイプによって指定されます。オリジンサーバは201ステータスコードを返す前にリソースを作成しなければならない（MUST）。アクションがすぐに実行できない場合、サーバは代わりに202（Accepted）応答で応答しなければならない（SHOULD）。
ので、どこへ行くのRESTfulな方法は、/users/1を指定Location:ヘッダで、/usersに投稿し201 Createdを返すことです。
私のREST APIは現在POSTをサポートしていますが、更新を許可するPUTもサポートしたいと考えています。だから、クライアント側から一意のIDを渡すという複雑さを避けるため、リソースを作成しようとせずにリソースが存在しない場合は、単純に404を返します。これはまだRESTfulと見なされますか？ – James
はい、 'PUT'は更新用に設計されています。 PUTが送信されたURIが利用可能なリソースを参照していない場合、404は返すべき合理的なものです。それがREST/JSONの場合は、レスポンスのメッセージ本文にjson形式のエラーメッセージを含めることができます。 '{"エラー "："リソースが存在しません。 "}'。しかし実際には、メッセージ本文に情報を送ることは、ステータスコードが伝える情報を追加する場合にのみ適切です。 「存在しない」というメッセージがある場合は、404で十分であり、メッセージ本文は必要ありません。 – Cheeso
クールなので、実際には 'PUT'を使って、作成したいかどうかを選択することができます（これは私が実際に解明しているものです）。私のシナリオで考えると、 'PUT'は（リソースが存在する場合）更新のために純粋に使用されます。ありがとう！ – James