| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| dev:web_api:v3:syncing [2019/03/10 16:54] – dstillman | dev:web_api:v3:syncing [2019/03/19 05:37] – [Full-Library Syncing] dstillman |
|---|
| GET <userOrGroupPrefix>/items?since=<version>&format=versions&includeTrashed=1 | GET <userOrGroupPrefix>/items?since=<version>&format=versions&includeTrashed=1 |
| |
| ''<version>'' is the ''[[#last-modified-version|Last-Modified-Version]]'' returned from the API for the last successfully completed sync process, or ''0'' when syncing a library for the first time. | ''<version>'' is the final ''[[#last-modified-version|Last-Modified-Version]]'' returned from the API for the last successfully completed sync process, or ''0'' when syncing a library for the first time. |
| |
| (The ''since'' parameter can also be used on ''.../tags'' requests (without ''format=versions'') by clients that don't download all items and wish to keep a list of all tags in a library up-to-date. It isn't necessary for clients that download all items to request updated tags directly, as item objects contain all associated tags.) | (The ''since'' parameter can also be used on ''.../tags'' requests (without ''format=versions'') by clients that don't download all items and wish to keep a list of all tags in a library up-to-date. It isn't necessary for clients that download all items to request updated tags directly, as item objects contain all associated tags.) |
| |
| - Treat the error as fatal and stop the sync without updating the local library version | - Treat the error as fatal and stop the sync without updating the local library version |
| - Mark the object as needing to be downloaded later and continue with the sync, updating the local library version at the end as if the sync had succeeded. In a future sync, add objects with this flag to the set of objects returned from the ''versions'' request so that their data is requested again even if the remote version is lower than the library version specified in ''?since=''. Ideally, retry these objects on a backoff schedule, since they may require either a server-side fix or a client update to save successfully. | - Add the object key to a list of objects needing to be downloaded later and continue with the sync, updating the local library version at the end as if the sync had succeeded. In a future sync, add objects on this list to the set of objects returned from the ''versions'' request so that their data is requested again even if the remote version is lower than the library version specified in ''?since=''. Ideally, retry these objects on a backoff schedule, since they may require either a server-side fix or a client update to save successfully. If these objects later appear as deleted, remove them from the list of objects. |
| |
| When processing a set of objects, it may be helpful to maintain a process queue for the sync run and move failing objects to the end of the queue in case they depend on other objects being retrieved. (In many cases, it's possible to sort objects beforehand to avoid such errors, such as by sorting parent collections before subcollections.) If a loop of the process queue completes without any objects being successfully processed, stop the sync. | When processing a set of objects, it may be helpful to maintain a process queue for the sync run and move failing objects to the end of the queue in case they depend on other objects being retrieved. (In many cases, it's possible to sort objects beforehand to avoid such errors, such as by sorting parent collections before subcollections.) If a loop of the process queue completes without any objects being successfully processed, stop the sync. |
Upgrade Storage