Unterschiedliche REST-Ressourceninhalte basierend auf Benutzerzugriffsberechtigungen

Question

Ich möchte basierend auf den Zugriffsrechten unterschiedliche Antworten auf dieselbe Frage für verschiedene Benutzer bereitstellen. Ich las diese Frage:

Excluding private data in RESTful response

Aber ich bin nicht einverstanden mit der akzeptierten Antwort, die besagt, dass Sie sowohl /people.xml und /unauthenticated/people.xml bieten sollten, da mein Verständnis von REST ist, dass eine bestimmte Ressource in einem leben soll bestimmten Ort, nicht mehrere, je nachdem, wie viel von seinen Informationen Sie interessiert sind.

Das System, das ich entwerfe, ist noch komplizierter als das. Angenommen, ein Benutzer hat mehrere Freundeskreise erstellt und ihnen unterschiedliche Zugriffsrechte zugewiesen. Zum Beispiel könnte mein "Bekanntschaftskreis" Zugang zu meinem Geburtstag haben und mein "beruflicher" Kreis könnte Zugang zu meiner Beschäftigungsgeschichte haben, aber nicht umgekehrt. Um die Antwort aus der Frage, die ich erwähnt habe, anzuwenden, muss ich eine Möglichkeit haben, alle Kreise des Benutzers zu erhalten (was ich aus Sicherheitsgründen geheim halten möchte) und dann durch /circles/a/users/42, /circles/b/users/42, /circles/c/users/42 und so weiter gehen und dann die Ergebnisse zusammenführen, um die maximale Menge an verfügbaren Informationen anzuzeigen. Offensichtlich gibt es nicht unbedingt einen einzigen Kreis, der alle Informationen erhält, die andere Kreise bekommen. Ich glaube, das ist schwierig genug (beachten Sie, dass ich wahrscheinlich dies mit mehreren Arten von Objekten tun muss und dass zukünftige Versionen möglicherweise eine andere Prozedur erfordern), aber was ist, wenn ich Sicherheitsbeschränkungen für einen bestimmten Benutzer trotz die Tatsache auferlegen möchte dass er auch in einigen meiner Kreise ist? Kann dieses Problem überhaupt gelöst werden? Selbst wenn ich mich weigere, auf eine der oben genannten Fragen zu antworten und eine neue Frage zu stellen, die mir eine Antwort geben könnte, würde es dennoch die Tatsache offenbaren, dass dieser spezielle Benutzer aufgrund individueller Zugangsbeschränkungen anders behandelt wird.

Was fehlt mir hier? Ist es mir überhaupt möglich, einen RESTful Web Service zu entwickeln?

Wenn die Schlussfolgerung ist, dass das Verhalten nicht RESTful ist, würde dies immer noch eine Situation darstellen, in der es moralisch in Ordnung wäre, den REST-Vertrag zu brechen? Wenn ja, was sind die negativen Auswirkungen? Gehe ich zum Beispiel Gefahr, dass Proxy-Caching-Probleme auftreten?

Answer 1

Ich stimme zu, dass die andere Lösung nicht richtig scheint. Es macht die URL-Struktur kompliziert und schwieriger, die Ressource zu finden. Wenn Sie jedoch REST richtig eingerichtet haben, sollte es keine Rolle spielen, wie die URL für die Ressource ist, da der Server sie kontrolliert (und sie frei verschieben kann, wie sie es für richtig hält). Wenn Ihr Client wirklich "REST" ist, würde er die benötigten Ressourcen durch vorherige Verhandlungen mit dem Server finden. Der Weg wäre also für den Kunden nicht wichtig. Ich mag es nicht, weil es verwirrend zu benutzen ist - nicht wegen einer Verletzung der REST-Prinzipien.

Aber das beantwortet wahrscheinlich Ihre Frage nicht - Was Sie nicht erwähnt haben, ist Ihre Sicherheitseinstellung - vermutlich übergeben Sie ein Session-Token mit der Anfrage als Teil des Anfrage-Headers. Ihre Back-End-Verarbeitung sollte daher in der Lage sein, bestimmte Sicherheitseinschränkungen zu berücksichtigen. Von dort bilden Sie die Liste mit der von Ihnen benötigten Geschäftslogik und geben eine begrenzte Ressource basierend auf der Sicherheit des Benutzers zurück, die an die Sitzung gebunden ist.

Für den Algorithmus selbst implementiert man normalerweise einen Algorithmus des kleinsten oder restriktivsten Typs, der die zulässigen Daten in eine Antwort zusammenführt (sehr ähnlich zu Java Realms oder dem Microsoft-Sicherheitsmodell von Microsoft).

Wenn die Daten für den eingeschränkten/nicht eingeschränkten Fall unterschiedlich strukturiert sind, können Sie zwei verschiedene Darstellungen der Daten erstellen und die Daten zurückgeben, für die der Benutzer berechtigt war. Der Client sollte sowieso nach den akzeptierten Mime-Antworttypen fragen, und er würde nur verschiedene Antworten basierend auf der Sitzungssicherheit im Anfrage-Header bereitstellen. Alternativ können Sie optionale Elemente mit den Repräsentationen angeben und die entsprechende Basis für die Autorisierung ausfüllen (obwohl das meiner Meinung nach ein wenig Hack-ee ist).

Answer 2

Nach Fielding Dissertation (es ist wirklich eine große Schrift):

Eine Ressource ist eine konzeptionelle Zuordnung zu einer Gruppe von Entitäten, nicht das Unternehmen, das zu einem bestimmten Zeitpunkt der Abbildung entspricht.

Mit anderen Worten, wenn Sie eine Ressource, die als „der anfordernden Benutzers zugeordneten Projekte“ und Darstellungen davon zugänglich durch eine URI von /projects definiert ist, Sie verletzen keine Einschränkungen von REST in eine Liste von Projekten Rückkehr (dh Repräsentation) für Benutzer A und eine andere (Repräsentation) für Benutzer B, wenn sie dieselbe URI abrufen. Auf diese Weise ist die Schnittstelle einheitlich/konsistent.

Zusätzlich dazu, REST schreibt nur, dass eine explizite Caching Anweisung mit der Antwort enthalten sein, ob die ‚Cache für diesen langen‘ oder ‚Cache gar nicht‘:

Cache Einschränkungen erfordern dass die Daten innerhalb einer Antwort auf eine Anfrage implizit oder explizit als cachefähig oder nicht cachefähig gekennzeichnet werden.

Wie Sie entscheiden, das zu verwalten, liegt bei Ihnen.

, dass im Auge behalten,

Sie sollten sich wohl fühlen eine Darstellung einer Ressource Rückkehr, die auf den Benutzer variiert in Abhängigkeit einer Darstellung einer bestimmten Ressource anfordert, solange Sie nicht die Einschränkungen verletzen werden einer einheitlichen Schnittstelle - Verwenden Sie keinen einzelnen Ressourcenbezeichner, um Darstellungen verschiedener Ressourcen zurückzugeben.

Wenn es hilft, bedenken Sie, dass der Server auch mit unterschiedlichen Darstellungen einer Ressource antwortet - XML ​​oder JSON, Französisch oder Englisch usw. Die mit der Anfrage gesendeten Credentials sind nur ein weiterer Faktor, mit dem der Server arbeiten kann Bestimmen, welche Repräsentation als Antwort zu senden ist. Dafür ist der Header-Bereich da.