Zur Zeit entwickle ich eine API und innerhalb dieser API möchte ich, dass die angemeldeten Benutzer zwei Ressourcen mögen / unähnlich oder favorisieren / ungünstigen können.
Mein "Like" -Modell (es ist eine Ruby on Rails 3-Anwendung) ist polymorph und gehört zwei verschiedenen Ressourcen:
%Vor%und
%Vor%Die Sache ist: Ich habe Zweifel, auf welche Art und Weise ich meine Ressourcen so rentabel wie möglich machen möchte. Ich habe bereits die nächsten beiden Möglichkeiten ausprobiert, um eine ähnliche / unähnliche Struktur in meinen URLs zu implementieren:
Fall A: (ähnlich / anders als das Mitglied der "Ressource" zu sein)
%Vor%und Fall B: ("likes" ist eine Ressource für sich)
%Vor%In beiden Fällen habe ich bereits eine Benutzersitzung, daher muss ich die ID des entsprechenden "like" Records beim Löschen / "unliking" nicht erwähnen.
Ich würde gerne wissen, wie Sie solche Fälle implementiert haben!
Update 15. April 2011: Mit "session" meine ich den Header HTTP Basic Authentication, der mit jeder Anfrage gesendet wird und eine verschlüsselte Kombination Benutzername: Passwort bereitstellt.
Ich denke, die Tatsache, dass Sie den Anwendungsstatus auf dem Server (Benutzersitzung, die die Benutzer-ID enthält) beibehalten, ist eines der Probleme hier. Das macht es viel schwieriger, als es sein muss, und es bricht die Statuslosigkeit -Einschränkung von REST.
In Fall A haben Sie URIs Operationen gegeben, die wiederum nicht RESTful sind. URIs identifizieren Ressourcen und Zustandsübergänge sollten unter Verwendung einer einheitlichen Schnittstelle ausgeführt werden, die allen Ressourcen gemeinsam ist. Ich denke, Fall B ist in dieser Hinsicht viel besser.
Also, mit diesen zwei Dingen würde ich etwas vorschlagen wie:
%Vor% Wir haben auch den zusätzlichen Vorteil, dass ein Benutzer nur ein "Gefällt mir" registrieren kann (sie können das "Gefällt mir" so oft wiederholen, wie sie möchten, und da das PUT idempotent ist, hat es das gleiche Ergebnis, egal wie oft wird es durchgeführt). DELETE ist ebenfalls idempotent. Wenn also eine Operation 'Im Gegensatz' aus irgendeinem Grund mehrmals wiederholt wird, bleibt das System in einem konsistenten Zustand. Natürlich können Sie POST auf diese Weise implementieren, aber wenn wir PUT und DELETE verwenden, können wir sehen, dass die Regeln, die zu diesen Verben gehören, wirklich gut zu unserem Anwendungsfall passen.
Ich kann mir auch eine andere nützliche Anfrage vorstellen:
%Vor%Das würde Details eines "Gefällt mir" zurückgeben, wie das Datum, an dem es gemacht wurde oder die Ordinalzahl (d. h. "Das war der 50. wie!").
Sie definieren eine "ähnliche" Ressource, eine Tatsache, dass eine Benutzerressource eine andere Ressource in Ihrem System mag. In REST müssen Sie also ein Ressourcennamensschema auswählen, das diese Tatsache eindeutig identifiziert. Ich würde vorschlagen (mit Songs als Beispiel):
%Vor% Dann erstellt PUT einen Liking und DELETE entfernt ihn. GET findet natürlich heraus, ob jemand ein bestimmtes Lied mag. Und Sie könnten GET /like/user/{user-id} definieren, um eine Liste der Lieder zu sehen, die ein bestimmter Benutzer mag, und GET /like/song/{song-id} , um eine Liste der Benutzer zu sehen, die einen bestimmten Song mögen.
Wenn Sie annehmen, dass der Benutzername von der vorhandenen Sitzung festgelegt wird, wie @joelittlejohn darauf hinweist, und nicht Teil des gleichen Ressourcennamens ist, verletzen Sie die Zustandslosigkeitsbeschränkung von REST und Sie verlieren einige sehr wichtige Vorteile. Zum Beispiel kann ein Nutzer nur seine eigenen Likes erhalten, nicht die Likes ihrer Freunde. Außerdem wird das HTTP-Caching unterbrochen, da die Likes eines Benutzers nicht von denen eines anderen unterschieden werden können.
Tags und Links ruby-on-rails-3 api rest