Eine einfache REST-API:
- GET: items / {id} - Gibt eine Beschreibung des Elements mit der angegebenen ID zurück
- PUT: items / {id} - Aktualisiert oder erstellt das Element mit der angegebenen ID
- LÖSCHEN: items / {id} - Löscht das Element mit der angegebenen ID
Nun die fragliche API-Erweiterung:
- GET: items? Filter - Gibt alle Artikel-IDs zurück, die dem Filter entsprechen
- PUT: items - Aktualisiert oder erstellt eine Reihe von Elementen, wie in der JSON-Nutzlast beschrieben
- [[ LÖSCHEN: Elemente - löscht eine Liste der von JSON-Nutzdaten beschriebenen Elemente ]] <- Nicht korrekt
Ich interessiere mich jetzt für die Recyclingfunktion für DELETE- und PUT-Vorgänge, auf die PUT / DELETE-Elemente / {id} problemlos zugreifen können.
Frage: Ist es üblich, eine solche API bereitzustellen?
Alternative: Im Zeitalter der Einzelverbindung ist die Ausgabe mehrerer Anfragen kostengünstig und würde atomarer funktionieren, da eine Änderung entweder erfolgreich ist oder fehlschlägt. Im Zeitalter der NOSQL-Datenbank ist jedoch möglicherweise bereits eine Änderung in der Liste eingetreten, selbst wenn die Anforderungsverarbeitung mit abbricht interner Server oder was auch immer aus irgendeinem Grund.
[AKTUALISIEREN]
Nach Berücksichtigung der Webstandards des Weißen Hauses und von Wikipedia: REST-Beispiele ist nun die folgende Beispiel-API vorgesehen:
Eine einfache REST-API:
- GET: items / {id} - Gibt eine Beschreibung des Elements mit der angegebenen ID zurück
- PUT: items / {id} - Aktualisiert oder erstellt das Element mit der angegebenen ID
- LÖSCHEN: items / {id} - Löscht das Element mit der angegebenen ID
Top-Ressourcen-API:
- GET: items? Filter - Gibt alle Artikel-IDs zurück, die dem Filter entsprechen
- POST: items - Aktualisiert oder erstellt eine Reihe von Elementen, wie in der JSON-Nutzlast beschrieben
PUT und DELETE on / items wird nicht unterstützt und ist verboten.
Die Verwendung von POST scheint der Trick zu sein, neue Elemente in einer umschließenden Ressource zu erstellen, ohne sie zu ersetzen, sondern anzuhängen.
HTTP Semantics POST Reads:
Erweitern einer Datenbank durch Anhängen
Wo die PUT-Methoden erfordern würden, die gesamte Sammlung zu ersetzen, um eine äquivalente Darstellung zurückzugeben, wie von HTTP Semantics PUT angegeben :
Ein erfolgreicher PUT einer bestimmten Darstellung würde bedeuten, dass ein nachfolgendes GET auf derselben Zielressource dazu führt, dass eine äquivalente Darstellung in einer 200 (OK) -Antwort zurückgegeben wird.
[UPDATE2]
Eine Alternative, die für den Aktualisierungsaspekt mehrerer Objekte noch konsistenter erscheint, scheint die PATCH-Methode zu sein. Der Unterschied zwischen PUT und PATCH wird im Entwurf des RFC 5789 wie folgt beschrieben :
Der Unterschied zwischen den PUT- und PATCH-Anforderungen spiegelt sich in der Art und Weise wider, wie der Server die eingeschlossene Entität verarbeitet, um die durch den Anforderungs-URI identifizierte Ressource zu ändern. In einer PUT-Anforderung wird die eingeschlossene Entität als geänderte Version der auf dem Ursprungsserver gespeicherten Ressource betrachtet, und der Client fordert an, dass die gespeicherte Version ersetzt wird. Bei PATCH enthält die beigefügte Entität jedoch eine Reihe von Anweisungen, die beschreiben, wie eine Ressource, die sich derzeit auf dem Ursprungsserver befindet, geändert werden sollte, um eine neue Version zu erstellen. Die PATCH-Methode wirkt sich auf die durch den Request-URI identifizierte Ressource aus und kann auch Nebenwirkungen auf andere Ressourcen haben. Das heißt, durch die Anwendung eines PATCH können neue Ressourcen erstellt oder vorhandene geändert werden.
Im Vergleich zu POST ist PATCH möglicherweise auch eine bessere Idee, da PATCH ein UPDATE zulässt, bei dem POST nur das Anhängen von Bedeutungen ohne die Möglichkeit einer Änderung zulässt.
POST scheint hier also falsch zu sein und wir müssen unsere vorgeschlagene API ändern in:
Eine einfache REST-API:
- GET: items / {id} - Gibt eine Beschreibung des Elements mit der angegebenen ID zurück
- PUT: items / {id} - Aktualisiert oder erstellt das Element mit der angegebenen ID
- LÖSCHEN: items / {id} - Löscht das Element mit der angegebenen ID
Top-Ressourcen-API:
- GET: items? Filter - Gibt alle Artikel-IDs zurück, die dem Filter entsprechen
- POST: items - Erstellt ein oder mehrere Elemente, wie in der JSON-Nutzlast beschrieben
- PATCH: items - Erstellt oder aktualisiert ein oder mehrere Elemente, wie in der JSON-Nutzlast beschrieben