Di mana dan apa sumber dayanya?
REST adalah semua tentang menangani sumber daya dengan cara yang tanpa kewarganegaraan dan dapat ditemukan. Itu tidak harus diimplementasikan melalui HTTP, juga tidak harus bergantung pada JSON atau XML, meskipun sangat disarankan bahwa format data hypermedia digunakan (lihat prinsip HATEOAS ) karena tautan dan id diinginkan.
Jadi, pertanyaannya menjadi: Bagaimana cara berpikir tentang sinkronisasi dalam hal sumber daya?
Apa itu sinkronisasi dua arah? **
Sinkronisasi dua arah adalah proses memperbarui sumber daya yang ada pada grafik node sehingga, pada akhir proses, semua node telah memperbarui sumber dayanya sesuai dengan aturan yang mengatur sumber daya tersebut. Biasanya, ini dipahami bahwa semua node akan memiliki versi terbaru dari sumber daya yang ada dalam grafik. Dalam kasus paling sederhana, grafik terdiri dari dua node: lokal dan jarak jauh. Lokal memulai sinkronisasi.
Jadi sumber daya utama yang perlu ditangani adalah log transaksi dan, oleh karena itu, proses sinkronisasi mungkin terlihat seperti ini untuk koleksi "item" di bawah HTTP:
Langkah 1 - Lokal mengambil log transaksi
Lokal: GET /remotehost/items/transactions?earliest=2000-01-01T12:34:56.789Z
Remote: 200 OK dengan isi yang berisi log transaksi yang berisi bidang-bidang yang mirip dengan ini
itemId - UUID untuk memberikan kunci primer bersama
updatedAt - cap waktu untuk memberikan titik terkoordinasi ketika data terakhir diperbarui (dengan asumsi bahwa riwayat revisi tidak diperlukan)
fingerprint- hash SHA1 dari isi data untuk perbandingan cepat jika updateAtbeberapa detik keluar
itemURI - URI lengkap ke item untuk memungkinkan pengambilan nanti
Langkah 2 - Lokal membandingkan log transaksi jarak jauh dengan miliknya
Ini adalah penerapan aturan bisnis tentang cara menyinkronkan. Biasanya, itemIdakan mengidentifikasi sumber daya lokal, lalu membandingkan sidik jari. Jika ada perbedaan maka perbandingan updatedAtdibuat. Jika ini terlalu dekat untuk dipanggil maka keputusan harus dibuat untuk menarik berdasarkan simpul lain (mungkin lebih penting), atau untuk mendorong ke simpul lain (simpul ini lebih penting). Jika sumber daya jarak jauh tidak ada secara lokal maka entri push dibuat (ini berisi data aktual untuk dimasukkan / diperbarui). Sumber daya lokal apa pun yang tidak ada dalam log transaksi jarak jauh diasumsikan tidak berubah.
Permintaan tarikan dibuat terhadap node jarak jauh sehingga data ada secara lokal menggunakan itemURI. Mereka tidak diterapkan secara lokal sampai nanti.
Langkah 3 - Dorong log transaksi sinkronisasi lokal ke jarak jauh
Lokal: PUT /remotehost/items/transactions dengan badan yang berisi log transaksi sinkronisasi lokal.
Node jarak jauh mungkin memproses ini secara sinkron (jika kecil dan cepat) atau asinkron (pikirkan 202 DITERIMA ) jika nampaknya akan menimbulkan banyak overhead. Dengan asumsi operasi sinkron, maka hasilnya akan menjadi 200 OK atau 409 CONFLICT tergantung pada keberhasilan atau kegagalan. Dalam kasus 409 CONFLICT , maka proses tersebut harus dimulai lagi karena ada kegagalan penguncian yang optimis di node jauh (seseorang mengubah data selama sinkronisasi). Pembaruan jarak jauh diproses berdasarkan transaksi aplikasi mereka sendiri.
Langkah 4 - Perbarui secara lokal
Data yang ditarik di Langkah 2 diterapkan secara lokal di bawah transaksi aplikasi.
Walaupun hal di atas tidak sempurna (ada beberapa situasi di mana lokal dan jarak jauh mungkin mendapat masalah dan memiliki data tarikan jarak jauh dari lokal mungkin lebih efisien daripada menjejalkannya ke dalam PUT besar) itu menunjukkan bagaimana REST dapat digunakan selama dua proses sinkronisasi directional.