次のような URL があります。
http://www.example.com/users/
PUT リクエストで新しいユーザーを作成したい:
requests.put('http://www.example.com/users/john/', data={'password': 1234})
実際、このリクエストは新しいユーザー リソースを作成し、201 "Created" ステータス コードを返します。そのリソースを更新したい場合は、次のようなリクエストを作成できます。
requests.put('http://www.example.com/users/john/', data={'username': 'jane'})
まあ、301 "Moved Permanently" ステータス コードと Location ヘッダーに新しく作成された URL を含む応答を返すことができます。問題は、コントローラーコードにそのようなロジックを実装しようとしているときに発生します。ロジックの一部に、次のようなユーザー名の存在をチェックするコードがあります。
if username in users:
# do something
新しいリソースを作成するために PUT を使用すると、この場合はユーザー名が既に存在すると言って、ユーザー名が存在しない場合、「ユーザー名は既に存在します。別のものを選択してください」のようなメッセージで 409「競合」ステータス コードを返すことができます。 「存在しません。201 の「作成済み」を返すだけです。論理的には、この作成操作は認証を必要としないため、「サインアップ」操作のようなものです。
一方、リソースの更新を要求するときは、ユーザーが自分のアカウント情報を更新できるようにするために、何らかの認証を行う必要があります。
したがって、ユーザー名変数を使用して実行する必要がある操作を決定し、ユーザー名が既に存在する場合、認証が必要か無効なユーザー名の応答でいつ応答するかわかりません。
私が最初に考えたのは、POST リクエストを使用して新しいユーザーを作成し、更新動作のためだけに PUT することでしたが、サーバーによって作成されていない識別子のリソースを作成するために POST を使用するのは悪い考えのようです。
私の質問は、PUT リクエストを使用して作成機能と更新機能の両方を実装する方法があるかどうかです。