2016-07-20 4 views
0

(json)REST APIを使用している間、私はuserリソースフィールド(email)がPUT内で上書きされないようにしたいと思いました。私が正しく理解していれば、PUTは古いものを置き換えるためにリソースの表現全体を含むべきです。例えばので409 Conflictステータスコードを使用して、HTTP PUTリクエスト内の一部のフィールドが更新されないようにすることはできますか

、APIからユーザーをフェッチする(一部のヘッダは簡略化のために出て左):

> GET /user/123 HTTP/1.1 
> Host: example.com 
> Authorization: Bearer XXXXX 
> Accept: application/json 

< HTTP/1.1 200 OK 
< Content-Type: application/json 
< 
< { "name": "John Smiht" 
< , "email": "[email protected]" 
< } 

そして、あなたはあなたがしたい、ジョン・スミスの名にタイプミスを修正したいと思います:

> PUT /user/123 HTTP/1.1 
> Host: example.com 
> Content-Type: application/json 
> 
> { "name": "John Smith" 
> , "email": "[email protected]" 
> } 

< HTTP/1.1 201 No Content 

誰かが別の電子メールアドレスを入力した場合、要求が処理されなかったことを示すために409を使用できますか? https://tools.ietf.org/html/rfc2616

  • 400 Bad Requestによると

    > PUT /user/123 HTTP/1.1 
    > Host: example.com 
    > Content-Type: application/json 
    > 
    > { "name": "John Smith" 
    > , "email": "[email protected]" 
    > } 
    
    < HTTP/1.1 409 Conflict 
    < Content-Type: application/json 
    < 
    < { "errorNumber": "XXX" 
    < , "errorMessage": "Not allowed to change e-mail address this way" 
    < } 
    

  • 403 Forbiddenを使用することができる(これはありません)不正な構文を示しますが、それはへのアクセスの詳細であるように私には思えます全体のリソースではなく、その一部ではない
  • 409 Conflictは、要求を満たすことができないという技術的な理由のようです。

私の質問は、どのステータスコードを使用すべきですか?


編集:受け入れられた回答に照らして;応答が

> PUT /user/123 HTTP/1.1 
> Host: example.com 
> Content-Type: application/json 
> 
> { "name": "John Smith" 
> , "email": "[email protected]" 
> } 

< HTTP/1.1 403 Forbidden 
< Content-Type: application/json 
< 
< { "errorNumber": "XXX" 
< , "errorMessage": "Not allowed to change e-mail address this way" 
< } 

答えて

0

になる私は、ユーザーが変更する権利を持っていなかった場合は、メールアドレス403は、サーバがユーザを理解できるように、右のコードであってもよいが、それに基づいて行動することを拒否うと思います。 (通常、範囲/特権が欠けていることを意味します)

+0

私はあなたの推論に同意すると思います。答えとして受け入れる:-) – mhogerheijde

関連する問題