response may be paged with pageToken on request, nextPageToken on response
request may limit fields returned with fields parameter
response: { etag, nextPageToken, more, tasks[] }
HEAD /tasks
can specify etag, receive 304
response will contain etag
paging, fields parameters not relevant
POST /tasks/:id
update a task, return result (new id)
if task isn't current, reject update
update is applied in full or not at all
request may limit fields returned with fields parameter
PATCH /tasks/:id
update a task, return result (new id)
if task isn't current, reject update
update is applied in full or not at all
request may limit fields returned with fields parameter
Possibly others, flesh this out.
GET /changes
alternative view of tasks, through diffs
parameters for "from" and (optional) "to"
response may be paged
response: { nextPageToken, more, changes[] }
change: { time, oldTask, newTask] }, oldTask may be empty
Backend:
User object stores the task collection etag, last modified time for headers. Task collection etag is updated when any
task is modified.
Question: How do we handle conflict resolution for offline modifications? Are there collaborative editing javascript libraries we can use? How do we handle shared tasks?
As for the API:
Backend: User object stores the task collection etag, last modified time for headers. Task collection etag is updated when any task is modified.
Question: How do we handle conflict resolution for offline modifications? Are there collaborative editing javascript libraries we can use? How do we handle shared tasks?