Де і які ресурси?
REST - це все, що стосується ресурсів у безгромадянському, відкритому вигляді. Її не потрібно реалізовувати через HTTP, а також не покладатися на JSON або XML, хоча настійно рекомендується використовувати формат даних гіпермедіа (див. Принцип HATEOAS ), оскільки посилання та ідентифікатори бажані.
Отже, виникає питання: як можна думати про синхронізацію з точки зору ресурсів?
Що таке двонаправлена синхронізація? **
Двонаправлена синхронізація - це процес оновлення ресурсів, присутніх на графіку вузлів, щоб наприкінці процесу всі вузли оновили свої ресурси відповідно до правил, що регулюють ці ресурси. Зазвичай це розуміється так, що всі вузли мали б останню версію ресурсів, наявну у графі. У найпростішому випадку графік складається з двох вузлів: локального та віддаленого. Місцевий ініціює синхронізацію.
Отже, ключовим ресурсом, на який потрібно звернутись, є журнал транзакцій, а отже, процес синхронізації може виглядати таким чином для колекції "items" під HTTP:
Крок 1 - Локальне отримання журналу транзакцій
Місцеві: GET /remotehost/items/transactions?earliest=2000-01-01T12:34:56.789Z
Віддалений: 200 ОК з тілом, що містить журнал транзакцій, що містить подібні до цього поля.
itemId - UUID для надання спільного первинного ключа
updatedAt - часова мітка для надання узгодженої точки, коли дані востаннє оновлювалися (за умови, що історія редагування не потрібна)
fingerprint- хеш SHA1 вмісту даних для швидкого порівняння, якщо updateAtйде кілька секунд
itemURI - повний URI для елемента, щоб дозволити його пізніше
Крок 2 - Місцевий порівнює журнал віддалених транзакцій із власним
Це застосування ділових правил, як синхронізувати. Зазвичай itemIdволевиявлення виявить локальний ресурс, а потім порівняє відбиток пальців. Якщо є різниця, то проводиться порівняння updatedAt. Якщо вони занадто близькі для виклику, тоді потрібно буде прийняти рішення вивести на основі іншого вузла (можливо, це важливіше) або натиснути на інший вузол (цей вузол важливіший). Якщо віддаленого ресурсу немає локально, робиться натискання (це містить фактичні дані для вставки / оновлення). Будь-які локальні ресурси, відсутні в журналі віддалених транзакцій, вважаються незмінними.
Запити на виклик виконуються проти віддаленого вузла, щоб дані існували локально, використовуючи itemURI. Вони не застосовуються локально до пізніше.
Крок 3 - Натисніть на журнал транзакцій локальної синхронізації на віддалений
Місцевий: PUT /remotehost/items/transactions з тілом, що містить локальний журнал транзакцій синхронізації.
Віддалений вузол може обробити це синхронно (якщо він невеликий і швидкий) або асинхронно (думаю 202 прийнято ), якщо це може призвести до великих витрат. Якщо припустити синхронну операцію, то результат буде або 200 ОК, або 409 КОНФЛІКТ, залежно від успіху чи невдачі. У випадку 409 CONFLICT процес слід запустити заново, оскільки стався оптимістичний збій блокування на віддаленому вузлі (хтось змінив дані під час синхронізації). Віддалені оновлення обробляються під власною транзакцією програми.
Крок 4 - Оновлення локально
Дані, витягнуті на етапі 2, застосовуються локально під транзакцією програми.
Хоча вищезазначене не є досконалим (є кілька ситуацій, коли локальні та віддалені можуть потрапляти в проблеми і мати віддалений витяг даних з локальних, ймовірно, більш ефективний, ніж вкладати їх у великий PUT), він демонструє, як REST можна використовувати під час дво- процес спрямованої синхронізації.