Confirmed users
176
edits
Apps/Sync/Spec2: Difference between revisions
→Authentication
No edit summary |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 146: | Line 146: | ||
{incomplete: true} | {incomplete: true} | ||
'''Note:''' there's a major problem here where a new assertion could create a new user, and then though the uuid changes etc, it means everything gets uploaded and downloaded from this new user's data. While this might be okay for the client, it should be noticed and confirmed by the client (as a kind of change of identity). | |||
= Clients = | = Clients = | ||
| Line 168: | Line 170: | ||
== POST == | == POST == | ||
Once you've retrieved the values, then you can send your own new values. | Once you've retrieved the values, then you can send your own new values. You'll send <tt>?since={since}</tt> just like with GET, because you must always incorporate every value before sending your own. This ensures that anyone who adds to the sync timeline is fully aware of everything preceding. | ||
The POST results, when successful, also update <tt>since</tt>. And the POST results when unsuccessful look just like a GET (since you needed to do a GET, right?) | |||
=== Quarantine === | === Quarantine === | ||
Sometimes you may not understand an object you receive; its type, or the format it is in. This might be because of corruption, but it might also be because another client has a newer/richer notion of the type than you do. ('''XXX''': conitnue) | Sometimes you may not understand an object you receive; its type, or the format it is in. This might be because of corruption, but it might also be because another client has a newer/richer notion of the type than you do. ('''XXX''': conitnue) | ||