Ich beginne mit der Arbeit an einem Projekt, das als eine Komponente die Notwendigkeit hat, Dateien von einem Server mit einem lokalen HTML5 IndexedDB-Speicher für die Offline-Nutzung zu synchronisieren, und später die Option, Änderungen aus dem IndexedDB-Speicher zurück auf den Server zu übertragen.
Aber bevor ich das Rad für etwas neu erfinde, das ein ziemlich einfacher Prozess sein sollte, hoffe ich, eine gut dokumentierte Standard-API (wenn nicht Client- und/oder Serverbibliotheken) zu finden, die den größten Teil der schweren Arbeit erledigt.
Ich möchte auch, dass mein Projekt ein wenig Offenheit beibehält, sodass die Einhaltung eines offenen Standards (selbst wenn ich in meinem speziellen Fall sowohl den client- als auch den serverseitigen Code schreiben muss) ein großer Gewinn ist.
WebDAV ist ein klarer Kandidat für diese Aufgabe, verfolgt aber viele Metadaten (Urheberschaftsinformationen usw.), die für mich nicht besonders relevant sind, und fügt viele HTTP-Verben hinzu, mit denen ich mich lieber nicht befassen möchte (to be entspricht eher einem modernen Verständnis von RESTful), und es ist im Allgemeinen ein schwereres Protokoll, als ich für meine begrenzte Aufgabe benötige.
Gibt es alternative freie Standards für eine solche API?
CouchDB und der eng verwandte JavaScript-Client PouchDB haben sich als fast genau das erwiesen, was ich mir vorgestellt hatte.
Es verwendet keine rein REST-konforme API, aber die Details sind sauber genug unter der vollständigen und gut dokumentierten API verborgen, dass es in meinem Fall keine Rolle spielt.
PouchDB hat eine sehr aktive Benutzer- und Entwickler-Community, und CouchDB beginnt nach einer kleinen Pause offenbar mit einer bevorstehenden Veröffentlichung von 2.0 wieder in Schwung zu kommen.
HTTP hat diese Eigenschaften bereits und ist der Punkt von REST.
Zitiert aus Spezifikation http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
BEKOMMEN
Die GET-Methode bedeutet, dass alle Informationen (in Form einer Entität) abgerufen werden, die vom Request-URI identifiziert werden. Bezieht sich der Request-URI auf einen datenproduzierenden Prozess, sind es die produzierten Daten, die als Entität in der Antwort zurückgegeben werden und nicht der Quelltext des Prozesses, es sei denn, dieser Text ist die Ausgabe des Prozesses.
STELLEN
Die PUT-Methode fordert an, dass die eingeschlossene Entität unter dem bereitgestellten Request-URI gespeichert wird. Wenn sich der Request-URI auf eine bereits vorhandene Ressource bezieht, SOLLTE die eingeschlossene Entität als modifizierte Version derjenigen betrachtet werden, die sich auf dem Ursprungsserver befindet. Wenn der Anforderungs-URI nicht auf eine vorhandene Ressource zeigt und dieser URI vom anfordernden Benutzeragenten als neue Ressource definiert werden kann, kann der Ursprungsserver die Ressource mit diesem URI erstellen. Wenn eine neue Ressource erstellt wird, MUSS der Ursprungsserver den Benutzeragenten über die Antwort 201 (Created) informieren. Wenn eine vorhandene Ressource geändert wird, SOLLTEN entweder die Antwortcodes 200 (OK) oder 204 (Kein Inhalt) gesendet werden, um den erfolgreichen Abschluss der Anfrage anzuzeigen. Wenn die Ressource nicht mit dem Request-URI erstellt oder geändert werden konnte, Es MUSS eine angemessene Fehlerantwort gegeben werden, die die Art des Problems widerspiegelt. Der Empfänger der Entität DARF KEINE Content-*-Header (z. B. Content-Range) ignorieren, die er nicht versteht oder implementiert, und MUSS in solchen Fällen eine 501-Antwort (nicht implementiert) zurückgeben.
LÖSCHEN
Die DELETE-Methode fordert an, dass der Ursprungsserver die durch den Request-URI identifizierte Ressource löscht. Diese Methode KANN durch menschliche Eingriffe (oder andere Mittel) auf dem Ursprungsserver außer Kraft gesetzt werden. Dem Client kann nicht garantiert werden, dass die Operation ausgeführt wurde, selbst wenn der vom Ursprungsserver zurückgegebene Statuscode anzeigt, dass die Aktion erfolgreich abgeschlossen wurde. Der Server SOLLTE jedoch KEINEN Erfolg anzeigen, es sei denn, er beabsichtigt zum Zeitpunkt der Antwort, die Ressource zu löschen oder an einen unzugänglichen Ort zu verschieben.
Der Sinn von REST ist, dass Sie sie nach Bedarf implementieren, um den Inhalt nach Bedarf aus Ihrem Back-End-Speicher zu speichern/speichern/löschen.
Das Speichern in IndexDB ist in Ordnung, aber Sie benötigen eine Form von Status. Mir ist keine Bibliothek bekannt, die dies tut, da es im Grunde sehr einfach ist. Möglicherweise möchten Sie eine Transaktionsprotokolltabelle führen, die Sie verwenden, um Informationen weiterzugeben.
(Ich glaube, Phonegap unterstützt IndexDB nicht, es verwendet WebSQL, aber es gibt eine Polyfüllung, um die IndexDB-API in WebSQL zu verwenden.)
Schwach