Also stimmen mein Chef und ich hier nicht zu und können keine Informationen darüber finden. Szenario: Ich möchte alle Benutzer für eine bestimmte Organisation abrufen. Wie lautet die URL?
mydomain.com/users/by/organisation/{orgId}
ODER
mydomain.com/organisation/{orgId}/users
Unsere Argumente:
Fall 1: Es wird erwartet, dass der Aufruf "Benutzer" zurückgibt und daher sollte sich die "Ressource" (erster Teil des Aufrufs) darauf beziehen.
Fall 2: Die Organisation "besitzt" / "ist das übergeordnete Element" des Benutzers und daher sollte die Organisation die erste sein.
Was sind deine Gedanken?
UPDATE:
Ich bin nicht besorgt darüber, was nach dem mydomain.com/{resource} kommt. Die Frage bezieht sich hauptsächlich darauf, ob sich die HTTP-Aktion (GET, POST, PUT, DELETE) auf die erste Ressource mydomain.com/users bezieht oder ob sie die Beziehung mydomain.com/organisations/users/ widerspiegelt.
Sie wissen wahrscheinlich, dass REST keine strengen Regeln hat, Sie können es mehr oder weniger frei implementieren, wie Sie wollen, aber hier sind meine 2 Cent
%Vor%Aber das hört sich nach einer guten URL an, weil es Ihnen irgendwie sagt, was es tut, wenn Sie es lesen, das ist keine großartige Idee. Normalerweise spezifiziert jedes URL-Segment eine Ressource , die existiert oder existieren kann.
In diesem Fall steht users für eine oder mehrere Ressourcen und ebenso für organisation , aber by nicht, es ist wahrscheinlich nicht mehr als ein Wort, um zu verdeutlichen, was die API tut.
Es wird erwartet, dass der Aufruf "Benutzer" zurückgibt und daher sollte sich die "Ressource" (erster Teil des Aufrufs) darauf beziehen.
Eine Ressource wird nicht unbedingt im ersten Teil der URL angegeben. Es kann der 2., 3. oder 10. sein, wenn Sie wollen
%Vor% Das sieht viel besser aus, aber ich denke, es gibt einen Punkt der Verbesserung. Sie sollten organisation in organisations umbenennen, um users
Dies
%Vor% ruft dann die Organisation mit der ID orgId und
ruft alle Benutzer ab, die zu dieser Organisation gehören.
Um es weiter einzugrenzen, könntest du
machen %Vor%um einen bestimmten Benutzer zu einer bestimmten Organisation zu bekommen
UPDATE: Ich bin nicht besorgt darüber, was nach dem kommt mydomain.com/{resource}. Die Frage bezieht sich hauptsächlich darauf, ob das HTTP-Aktion (GET, POST, PUT, DELETE) sollte sich auf die erste beziehen Ressource mydomain.com/users oder ob es die Beziehung mydomain.com/organisations/users/.
Um Ihr Update zu beantworten:
Ich habe es bereits oben erwähnt; Eine Ressource wird nicht unbedingt im ersten Teil der URL angegeben. . Wenn sich die Qualität der URL verbessert, indem Sie die gewünschte Ressource in den URL-Bereich verschieben, gehen Sie vor und machen Sie dies
Es gibt einen konzeptionellen Unterschied zwischen dem, was Sie hier zeigen wollen. Die erste ist eine Filterung aller Benutzerressourcen im System basierend auf einigen Kriterien. Die zweite zeigt die Benutzerressourcen, die zu einer Organisation gehören.
Die zweite URL ist in Ordnung, um Benutzer anzuzeigen, die zu einer Organisation gehören, die ich denke.
Die erste URL filtert effektiv die Benutzer, die Sie von allen Benutzern sehen möchten.
Die Verwendung der URL könnte für die Filterung in Ordnung sein, obwohl die Verwendung von URL-Querystring ebenfalls in Ordnung ist. also
%Vor%könnte vorzuziehen sein. Die URLs können noch Querystrings enthalten und erholsam sein.
Macht es wirklich Sinn für DELETE mydomain.com/users/organisation/{orgid} ? Würden Sie erwarten, dass die Organisation gelöscht wird? Wenn nicht, dann zeigt dies nicht wirklich auf eine Ressource und Sie tun eine Suche und sollten wahrscheinlich Querystrings verwenden.
Es gibt andere Optionen für die Suche, wie die Suchkriterien zu einem Objekt erster Klasse zu machen oder eine der anderen Filtertechniken in diese Frage oder diese Frage
Lassen Sie mich damit beginnen: technisch sollte es eigentlich nicht wichtig sein. REST gibt an, dass URLs über Links wie Links auf normalen (HTML-) Webseiten erkennbar sein müssen.
Eine konsistente, selbsterklärende URL-Struktur wird jedoch keinerlei Schaden anrichten. Ich würde eine hierarchische Struktur in URLs vorschlagen:
/organisations gibt eine Liste aller Organisationen /organisations/123 gibt eine bestimmte Organisation (# 123) /organisations/123/users gibt eine Liste der Benutzer zurück, die dieser Organisation zugeordnet sind Eine Alternative wäre eine Abfragezeichenfolge zum Filtern:
/users gibt eine Liste aller Benutzer /users?organisation=123 gibt eine Liste der Benutzer zurück, die dieser Organisation zugeordnet sind Aus dieser hierarchischen Perspektive würde /users/by/organisation/123 nicht viel Sinn ergeben. Was wäre das Ergebnis des Aufrufs von /users/by/organisation ? Oder /users/by ?
mydomain.com/users/by/organisation/ {orgId}
Was bedeutet "nach"? Das hat keine Beziehung zu irgendetwas. Versuche zufällige Wörter aus der URL zu entfernen .
Fall 1: Es wird erwartet, dass der Aufruf "Benutzer" zurückgibt und daher sollte sich die "Ressource" (erster Teil des Aufrufs) darauf beziehen.
Das ist keine Regel, die RESTful APIs erzwingen oder erwarten. Es ist wirklich nicht so üblich in der Branche, und ich habe mit einer Menge von APIs gearbeitet. Betrachten Sie es als einen Ordner.
Sie sehen es wie einen Programmierer an, so wie es SOAP oder eine PHP-Funktion ist, und versuchen, getUsersByOrganization($orgId) zu machen, und so funktioniert REST nicht. :)
Wenn Sie bei Fall 1 bleiben müssen (erstes URI-Segment = Rückgabetyp), dann tun Sie dies:
Das ist perfekt RESTful und es ist im Wesentlichen nur ein Filter. Du könntest beides tun, aber ich würde es nicht tun. Es ist eine Beziehung, die dort keinen Platz hat. Ich versuche, Filter auf Dinge wie:? Active = true
zu haltenDas zweite ist besser. Wenn Sie den URI nach unten führen, sollte die Anforderung eingeschränkt werden, entweder als Filter oder zum Anzeigen von Parent-Child-Objekten. Benutzer gehören zu einer Organisation, also sollte es Organisation / Benutzer sein. Aber ich würde auch die "Organisation" Ebene der URI loswerden, wenn möglich.
%Vor%Bei REST spielt die URI-Struktur nur aus menschlicher Perspektive eine Rolle. Es spielt keine Rolle aus der Perspektive des REST-Clients, da es sich um einen mit Semantik versehenen Link handelt.
Um Ihre Frage zu beantworten, ist es wichtig, was Sie beschreiben möchten, Beziehungen oder Benutzer. Wenn Sie Beziehungen hinzufügen und entfernen möchten, müssen Sie eine Beziehungssammlung definieren. Wenn Sie Benutzer hinzufügen und entfernen möchten, müssen Sie eine Benutzersammlung definieren. Dies ist nur durch Manipulation wichtig. Mit GET können Sie jede Art von Abfrage definieren, die eine Menge Benutzer zurückgibt ...
Tags und Links rest restful-architecture naming-conventions