Wie eine schreibgeschützte Eigenschaft in einer REST Api

Question

darstellen, wenn Sie eine REST API haben, die hypermedia-driven (HATEOAS) Sie leicht das Verhalten des Kunden, indem oder Weglassen Links in der Antwort (_links) ändern können, ist. Dadurch kann ein Client die Testberechtigungen für die Operationen, die im aktuellen Zustand einer resource möglich sind, vollständig vergessen (die Verknüpfung zu der Operation ist vorhanden oder nicht).

Zusätzlich können Sie Eigenschaften in der Antwort auslassen, wenn der aktuelle Benutzer keine Berechtigung zum Anzeigen hat.

Auf diese Weise erfolgt die Autorisierung vollständig auf dem Server (und steuert Aktionen und Eigenschaften, die für die Ausführung/Ansicht geeignet sind).

Aber was, wenn ich eine read-only Eigenschaft haben möchte? Es ist kein Problem für die RESTAPI, die Eigenschaft zu ignorieren, wenn es in der Anfrage vorhanden ist (_POST_ OR _PUT_). es wird einfach nicht gerettet werden. Aber wie kann ein Client zwischen schreiben und lesen Sie nur Eigenschaften, um den Benutzer entsprechende Steuerelemente (wie ein deaktiviertes Eingabefeld in HTML) zu präsentieren?

Das Ziel ist es, nie die client request Berechtigungen eines Benutzers, sondern eine vollständig Ressource client/frontend zu haben.

Jede Hilfe ist sehr geschätzt :-)

Answer 1

Wenn ich Ihre Frage falsch verstanden, ich entschuldige mich im Voraus. Damit wird gesagt ...

Aber wie kann zwischen Schreib- und Lese nur Eigenschaften zu präsentieren, die Benutzer über die entsprechenden Kontrollen (wie ein behindertes Eingabefeld in HTML)

Gut ein Client unterscheiden Dafür gibt es mehrere Lösungen. Die einfachste ich persönlich denken kann, ist jede Eigenschaft ein Objekt mit einem einfachen Aufbau von so etwas wie zu machen:

... 

    someProperty: { 
     value: 'some value', 
     access: 'read-only' 
    }, 
    someOtherProperty: { 
     value: 'some value', 
     access: 'write' 
    } 
    ... 

Sie offensichtlich so kreativ wie Sie wollen mit, wie Sie die „access“ Ebene der repräsentieren Eigenschaft (mit enums, booleans, Ändern access zu isReadOnly oder was auch immer).

Danach weiß die Person, die die API verwendet, dass sie schreibgeschützt ist oder nicht. Wenn sie einen "write" -Wert für eine "read-only" -Eigenschaft als Teil der POST-Nutzlast senden, sollten sie nicht weniger als eine 403-Antwort erwarten.

Edit: Falls Sie die Eigenschaften auf diese Weise nicht verändern können, gibt es eine Reihe anderer Möglichkeiten, wie Sie dies noch erreichen können:

• Schreib Dokumentation, was jede Eigenschaft
Zugriff erklärt hat
• Erstellen Sie eine Route, an die der Benutzer eine oder mehrere Eigenschaften senden kann, um eine Antwort zu erhalten, die die Zugriffsebene jeder Eigenschaft angibt (Antwort: {propName: 'schreibgeschützt', propName2: 'schreib' usw.)
• Rückgabe einer EigenschaftAccess-Map als Teil der Antwort (Zuordnen von Eigenschaften zu Zugriffsebenen).

Ende des Tages brauchen Sie nur eine Möglichkeit, eine Eigenschaft mit einer Zugriffsebene zuzuordnen. Dies hängt jedoch davon ab, welche Einschränkungen und Anforderungen für die API gelten, welche Änderungen Sie vornehmen können und was sowohl für Ihre Kunden als auch für die Geschäftsanforderungen akzeptabel ist.