Estoy comenzando a trabajar en un proyecto que tiene, como un componente, la necesidad de sincronizar archivos de un servidor a una tienda HTML5 IndexedDB local para uso sin conexión, y luego, la opción de enviar cambios de la tienda IndexedDB al servidor.
Pero antes de reinventar la rueda en algo que debería ser un proceso bastante sencillo, espero encontrar una API estándar bien documentada (si no bibliotecas de cliente y/o servidor) para hacer la mayor parte del trabajo pesado.
También me gustaría que mi proyecto mantenga un poco de apertura, por lo que adherirse a un estándar abierto (incluso si tengo que escribir tanto el código del lado del cliente como del lado del servidor en mi caso particular) es una gran victoria.
WebDAV es un claro candidato para esta tarea, pero rastrea muchos metadatos (información de autoría, etc.) que no son particularmente relevantes para mí, y agrega muchos verbos HTTP, que preferiría no tratar (to be más consistente con una comprensión moderna de RESTful), y generalmente es un protocolo más pesado de lo que necesito para mi tarea limitada.
¿Existen estándares gratuitos alternativos para dicha API?
CouchDB y el cliente de JavaScript estrechamente relacionado, PouchDB , han demostrado ser casi exactamente lo que estaba imaginando.
No utiliza una API compatible con REST puramente, pero los detalles están lo suficientemente limpios ocultos debajo de la API completa y bien documentada, que en mi caso no importa.
PouchDB tiene una comunidad de usuarios y desarrolladores muy activa, y CouchDB está comenzando a volver al ritmo de las cosas, aparentemente después de un pequeño paréntesis, con el próximo lanzamiento de 2.0.
HTTP ya tiene estas características y es el punto de REST.
Citado de la especificación http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
CONSEGUIR
El método GET significa recuperar cualquier información (en forma de entidad) identificada por la URI de solicitud. Si Request-URI se refiere a un proceso de producción de datos, son los datos producidos los que se devolverán como la entidad en la respuesta y no el texto fuente del proceso, a menos que ese texto sea el resultado del proceso.
PONER
El método PUT solicita que la entidad adjunta se almacene bajo el URI de solicitud proporcionado. Si Request-URI hace referencia a un recurso ya existente, la entidad adjunta DEBE considerarse como una versión modificada de la que reside en el servidor de origen. Si el URI de solicitud no apunta a un recurso existente, y el agente de usuario solicitante puede definir ese URI como un nuevo recurso, el servidor de origen puede crear el recurso con ese URI. Si se crea un nuevo recurso, el servidor de origen DEBE informar al agente de usuario a través de la respuesta 201 (Creado). Si se modifica un recurso existente, se DEBEN enviar los códigos de respuesta 200 (OK) o 204 (Sin contenido) para indicar que la solicitud se completó con éxito. Si el recurso no se pudo crear o modificar con la URI de solicitud, DEBE darse una respuesta de error adecuada que refleje la naturaleza del problema. El destinatario de la entidad NO DEBE ignorar ningún encabezado Content-* (por ejemplo, Content-Range) que no comprenda o implemente y DEBE devolver una respuesta 501 (No implementado) en tales casos.
ELIMINAR
El método DELETE solicita que el servidor de origen elimine el recurso identificado por Request-URI. Este método PUEDE ser anulado por la intervención humana (u otros medios) en el servidor de origen. No se puede garantizar al cliente que la operación se haya realizado, incluso si el código de estado devuelto desde el servidor de origen indica que la acción se ha completado con éxito. Sin embargo, el servidor NO DEBE indicar el éxito a menos que, en el momento de dar la respuesta, tenga la intención de eliminar el recurso o moverlo a una ubicación inaccesible.
El punto de REST es que los implemente según sea necesario para almacenar/guardar/eliminar el contenido según sea necesario de su tienda de back-end.
El almacenamiento dentro de IndexDB está bien, pero necesitará algún tipo de estado. No conozco una biblioteca que haga esto, ya que es básicamente muy simple. Es posible que desee mantener una tabla de registro de transacciones que utilice para propagar información.
(Creo que phonegap no es compatible con IndexDB, usa WebSQL pero hay un relleno poli para usar la API de IndexDB en WebSQL disponible)
endeble