Ich komme aus der RPC-Welt, aber ich untersuche derzeit, ob die Verwendung von REST eine gute Idee für mein Projekt ist. Soweit ich von Wikipedia verstehe, besteht die Grundidee von RESTful-Services darin, den Zugriff auf Sammlungen und ihre einzelnen Elemente zu ermöglichen.
In meinem Fall wäre der Server ein Messgerät. Ich muss in der Lage sein, die Messroutine zu starten, zu stoppen und anzuhalten und die Daten jederzeit zu lesen.
Momentan überlege ich Folgendes:
Ich bin mir jedoch nicht sicher, ob dies dem REST-Modell entspricht, da ich hier nicht wirklich mit Sammlungen oder Elementen arbeite.
Meine Frage: Wie würde ich auf eine Singleton-Ressource zugreifen und die Start / Stopp-Anforderungen an den Server brechen die RESTful statuslose Einschränkung?
Du arbeitest immer noch an einer Ressource, und die Art, wie du sie kaputt gemacht hast, klingt gut für mich. Fielding erwähnt ausdrücklich temporäre Dienste im REST-Kapitel :
Die Schlüsselabstraktion von Informationen in REST ist eine Ressource. Irgendein Informationen, die benannt werden können, können eine Ressource sein: ein Dokument oder ein Bild, ein temporaler Dienst (z. B. "heutiges Wetter in Los Angeles")
Vielleicht wäre es sinnvoll, jeder Messung eine eindeutige ID zu geben. Auf diese Weise können Sie sich eindeutig auf jede Messung beziehen (Sie müssen nicht einmal die alten speichern, aber wenn sich jemand auf eine alte Messung bezieht, können Sie ihnen sagen, dass das, was sie anfordern, nicht mehr aktuell ist).
Nein, Ihr Ansatz ist nicht REST-konform, denn wenn ich den Arbeitsablauf verstehe, würden Sie die Ressource löschen, um die Messung zu stoppen, und dann die Ressource dazu bringen, das Endergebnis auszulesen. Wenn eine Ressource gelöscht wird, bedeutet dies, dass GET nicht mehr vorhanden ist.
Die Tatsache, dass Ihre Ressource ein Singleton ist, ist überhaupt kein Problem. Das Problem liegt in der Art, wie Sie Verben und Zustand zuordnen.
Ihre Beschreibung ist etwas abstrakt, lassen Sie uns etwas konkreter werden: Nehmen wir an, dass das fragliche Instrument die Winkelgeschwindigkeit eines Schwungrads in Radianten / Sekunde misst. Dieses Instrument hat einige Kosten, die mit der Messung verbunden sind, so dass der Client in der Lage sein muss, die Messung für einige Zeiträume als kostensparende Maßnahme zu deaktivieren. Wenn dies in etwa Ihrem Szenario entspricht, sollte die folgende Beschreibung für Ihr Szenario gelten.
Sehen wir uns jetzt Ihre Verben an.
GET gibt eine Repräsentation einer Ressource zurück. Also, wenn Sie GET /measure , sollte es einige Daten zurückgeben, die die aktuelle Messung darstellt.
PUT erstellt oder aktualisiert eine bestimmte, benannte Ressource. Die Ressource wird anhand ihrer URL benannt. So bedeutet PUT /measure , dass Sie den Status einer Ressource mit dem Namen /measure aktualisieren oder diese Ressource erstellen, wenn sie nicht bereits vorhanden ist. In Ihrem Fall ist der Wert des Instruments schreibgeschützt: Wir können keinen Wert für Radiant / Sekunde in das Instrument schreiben. Aber der pausierte / aktive Zustand des Instruments ist veränderbar, daher sollte PUT /measure einen Körper enthalten, der den Zustand des Instruments modifiziert. Sie könnten hier viele verschiedene Darstellungen verwenden, aber ein einfacher Ansatz wäre ein Anfragekörper wie active=true oder active=false , um anzugeben, wie der neue Zustand des Instruments aussehen soll.
POST ähnelt PUT , außer dass der Client den Namen der Ressource nicht angibt, die erstellt oder aktualisiert werden soll. In einer anderen API könnte der Client beispielsweise POST /articles verwenden, um einen neuen Artikel zu erstellen. Der Server erstellt eine Ressource und gibt ihr einen Namen wie /articles/1234 . Anschließend wird der Client über diesen neuen Namen informiert, indem ein 201 CREATED HTTP-Code zurückgegeben und ein Location: /articles/1234 -Kopf hinzugefügt wird, um dem Client mitzuteilen, wo sich die neue Ressource befindet . In Ihrem Szenario ist POST kein sinnvolles Verb, da Sie immer wissen, wie der Name Ihrer Singleton-Ressource lautet.
DELETE bedeutet, dass Sie eine Ressource entfernen, und da eine Ressource durch eine URL identifiziert wird, bedeutet DELETE /measure , dass /measure nicht mehr existiert. Ein nachfolgender GET /measure sollte entweder 404 NOT FOUND oder 410 GONE zurückgeben. In Ihrem Fall kann der Client das Instrument nicht wirklich zerstören, daher ist DELETE kein aussagekräftiges Verb.
Zusammengefasst wäre ein RESTful-Design für Ihren Dienst also PUT /measure mit einem Anfragetext, der dem Gerät mitteilt, ob es aktiv oder nicht aktiv sein soll (pausiert) und GET /measure , um die aktuelle Messung zu lesen. Wenn Sie GET /measure auf einem angehaltenen Instrument verwenden, sollten Sie wahrscheinlich einen 409 CONFLICT HTTP-Status zurückgeben. Ihr Dienst sollte nicht POST oder DELETE verwenden.
Aufbauend auf der letzten Antwort. Hier ist, wie Sie es vielleicht brechen möchten