Wie sollte ein RESTful-Service schreibgeschützte Eigenschaften auf änderbaren Ressourcen verfügbar machen?

Question

Ich arbeite am Entwerfen einer Ressource für diesen Dienst, die eine Reihe von veränderbaren Eigenschaften und eine Reihe von unveränderlichen (z. B. status, die vom Dienst generiert wird und nicht etwas, das der Client ändern kann) hat.

Ich muss dies in Antworten auf GET Anfragen für die Ressource enthalten, aber bin mir nicht sicher, was zu tun ist, wenn jemand dann die Ressource mit einer PUT Anfrage sendet.

Das Erzwingen des Anrufers zu wissen, welche Eigenschaften unveränderlich sind, fühlt sich falsch an, aber stillschweigend verwerfen Aktualisierungen fühlen sich auch falsch. Die Antwort mit der aktualisierten Ressource auf die Anfrage PUT könnte das Problem lösen, aber es ist unvollkommen, da der Anrufer keine Diff seiner Anfrage und die Antwort des Dienstes machen sollte, um herauszufinden, ob eine Eigenschaft akzeptiert wurde.

Irgendwelche Gedanken auf dem richtigen Weg?

P.S. Ich schaute auf How should I update a REST resource?, aber es ist anders als diese Frage und fördert eine übermäßig gesprächige API-Design.

Answer 1

Ich würde vorschlagen, den Richtlinien zu http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.10 zu folgen. Die Definition von HTTP 409 umfasst Folgendes:

1) Die Anforderung konnte aufgrund eines Konflikts mit dem aktuellen Status der Ressource nicht abgeschlossen werden.

2) Der Antworttext SOLLTE genügend Informationen enthalten, damit der Benutzer die Ursache des Konflikts erkennen kann.

Da also Änderungen an unveränderbaren Eigenschaften ein Problem mit dem Status der Ressource sind, scheint HTTP 409 zu gelten.

Für die Kommunikation des Problems mit dem Client scheint die Anleitung darin zu bestehen, Details in den Antworttext aufzunehmen.

Sie könnten auch die Änderbarkeit von Eigenschaften in der Repräsentation selbst (auf der GET) kommunizieren. Beispielsweise.

<MyObject> 
    <Foo>17</Foo> 
    <Bar readOnly="true">22</Bar> 
    .... 

Answer 2

Sie könnten die Antworten Ihrer API so entwerfen, dass die schreibgeschützten Eigenschaften tatsächlich von den änderbaren Eigenschaften getrennt sind. Zum Beispiel:

{ 
    id: 42, 
    status: "terrific", 
    properties: { 
     // mutable properties here 
    } 
} 

Ich habe beide geschrieben und APIs konsumiert, die dies tun, und es ist gut gelungen.

Answer 3

Verwenden Sie HTTP PATCH mit JSON-Patch-Dokumenten - damit können Sie genau die Eigenschaften festlegen, die Sie ändern möchten. Siehe http://tools.ietf.org/html/rfc6902.

Aber es ist nichts falsch daran, sowohl unveränderliche als auch veränderbare Elemente zurückzugeben. Der Server ist frei, zu ignorieren, an was auch immer er nicht Änderungen vornehmen möchte. Ich habe eine ausführliche Diskussion zu diesem Thema hier geschrieben: http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html