Ist es erlaubt, den 409 Konfliktstatuscode zu verwenden, um zu verhindern, dass einige Felder in einer HTTP PUT Anfrage aktualisiert werden?

Question

Während ich an einer (json) REST API arbeitete, kam ich auf die Situation, dass wir eine Darstellung einer user Ressource haben Ich wollte verhindern, dass ein Feld (email) innerhalb einer PUT überschrieben wird. Wenn ich richtig verstehe, sollte ein PUT die gesamte Darstellung der Ressource enthalten, um die alte zu ersetzen.

So zum Beispiel, wenn ein Benutzer aus dem API-Abrufen (Einige Header links der Einfachheit halber aus):

> 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": "john.smith@example.com" 
< } 

Und Sie haben den Tippfehler in John Smiths Namen zu bestätigen möchten, können Sie tun würde:

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

< HTTP/1.1 201 No Content 

Nun, wenn jemand eine andere E-Mail-Adresse setzen waren, bin ich ein 409 benutzen darf die Anforderung, um anzuzeigen, wurde nicht bearbeitet?

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

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

Nach https://tools.ietf.org/html/rfc2616

• A 400 Bad Request zeigt fehlerhafte Syntax (die dies nicht)
• A 403 Forbidden verwendet werden könnte, aber es scheint mir, dass es mehr über den Zugriff auf die ist Gesamte Ressource, nicht Teil davon
• Eine 409 Conflict scheint über einen technischen Grund zu sein, nicht in der Lage zu sein, die Anfrage zu erfüllen, und nicht über Privilegien, etwas zu tun.

Also meine Frage ist: welchen Statuscode soll ich verwenden?

---

Edit: im Licht der angenommenen Antwort; die Antwort würde

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

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

Answer 1

würde ich sagen, wenn der Benutzer E-Mail-Adresse 403 nicht das Recht hat, zu ändern, der richtige Code als der Server die Benutzer verstanden, aber sie weigern, es zu handeln wäre. (In der Regel bedeutet es fehlende Umfang/Privilegien)