it-swarm.com.de

URI-Design für viele-zu-viele-Beziehungen: Beratung erforderlich

Ich stecke fest, URIs für eine Viele-zu-Viele-Beziehung zwischen Benutzern und anderen Ressourcen zu entwerfen. Insbesondere habe ich Schwierigkeiten, die Konsequenzen verschiedener Ansätze vorherzusagen.

Bei den Ressourcentypen user und widget (user steht für einen registrierten Benutzer) haben authentifizierte (angemeldete) Benutzer Schreibzugriff auf alle Widgets und Gäste Lesezugriff. Die Benutzer-Widget-Beziehung enthält auch Daten (z. B. Anzahl der Bearbeitungen), die im Idealfall auch von Gästen (und, -) gelesen (also adressiert werden sollten. wie Lèse weiter unten ausführt , andere Benutzer). In Beispielen werden der Übersichtlichkeit halber Ganzzahlen für eindeutige Bezeichner verwendet.

Gäste können Widget Nr. 12 unter anzeigen

/widgets/12

Was bedeuten verschiedene mögliche URIs für den authentifizierten Benutzer # 34 zum Lesen/Schreiben des Widgets # 12 und optional für einen Gast zum Lesen der relationalen Daten zwischen den beiden? (Machen Sie sich keine Sorgen um eine umfassende Antwort, Beobachtungen für oder gegen bestimmte Optionen wären ebenfalls sehr wertvoll.).

/widgets/12

(Benutzer ist implizit basierend auf der Authentifizierung, Gast kann keine Benutzer-Widget-Beziehung angeben.)

/users/34/widgets/12

(beide Seiten der Beziehung explizite, implizite Hierarchie zwischen Ressourcen)

/users/34/widgets/12 and /widgets/12/users/34

(gleich, ohne Hierarchie)

/user-widget/34,12

(Relation als Ressource, explizit, aber möglicherweise mehr als der Benutzer wissen muss)


Gerne mache ich nähere Angaben oder füge URI-Vorschläge anderer hinzu. Kommentieren Sie einfach, wenn Sie möchten, dass ich etwas hinzufüge.

4
Ian Mackinnon

Die URL für den Zugriff auf das Widget sollte für alle Benutzer gleich sein. Die Kontrolle darüber, was angezeigt werden soll oder über welche Funktionen der Benutzer verfügt, hängt von der Benutzer-ID ab, die beispielsweise in einer Sitzungsvariablen gespeichert werden kann.

Wenn also Widget/12 geladen wird, sollte Ihre Webseite überprüfen, wer die Benutzer-ID in der Sitzungsvariablen ist, welche Berechtigungen sie haben, und dann die Seite basierend auf diesen Berechtigungen formatieren.

3
milesmeow

Wie ermöglicht das Formular /widgets/12 es Gästen, die Widgets zu lesen - oder Benutzern, die Widgets anderer Benutzer zu lesen? Oder planen Sie die Implementierung mehrerer Formulare?

Persönlich würde ich so etwas tun:

/widget/id:12/user:665
/widget/12/665
/widget/12?user=665

Letztendlich spielt die URL jedoch keine Rolle, es sei denn, dies wird etwas sein, auf das Benutzer direkt zugreifen möchten. Wenn es sich nur um einen Speicherort für ein einbettbares Skript, einen Datenfeed oder eine andere Art von Dienst handelt, können Sie eine beliebige URL verwenden. In diesem Fall würde ich einfach Folgendes verwenden:

/widget?id=12&uid=665

Bearbeiten:
Ich bevorzuge es, nur das Widget unter /widget zu bedienen, da dies die Ressource ist. Ich gehe davon aus, dass die Benutzer-Widget-Beziehung durch die Art des Widgets impliziert wird. Das Hinzufügen von users zur Pfadhierarchie ist daher nicht erforderlich.

Wenn Sie möchten, dass Benutzer die Widgets eines bestimmten Benutzers durchsuchen können, ist das Formular /users/34/widgets/12 vorzuziehen.

2
Lèse majesté

Wenn es um Authentifizierung geht, würde ich sie überhaupt nicht über die URL weiterleiten. Was hindert mich daran, die Benutzer-ID in der URL zu ändern und Berechtigungen zu erhalten, die ich nicht erhalten soll?

0
GSto