Konteks

Karena kewarganegaraan gaya arsitektur REST yang melibatkan setiap permintaan berdiri sendiri, menyebabkan server tidak pernah menyimpan informasi tentang klien.

Dengan demikian, kontrol konkurensi pesimis tidak cocok karena akan mengharuskan server menyimpan klien mana yang mendapatkan kunci pada sumber daya. Kontrol konkurensi optimis kemudian digunakan, dengan bantuan Etagtajuk. (btw, seperti yang saya tanyakan di sana /programming/30080634/concurrency-in-a-rest-api )

Masalah

Masalah utama dengan mekanisme kontrol konkurensi optimis adalah bahwa Anda mengizinkan sepanjang waktu, semua klien, untuk melakukan operasi apa pun.

Dan saya ingin menghindari itu tanpa melanggar prinsip statelessness REST. Maksud saya, semua klien tidak dapat melakukan operasi apa pun kapan saja.

Pertanyaan

Dalam pikiran saya, itu mungkin dengan mekanisme kontrol konkurensi semi-optimis , seperti itu:

• Klien dapat meminta token
• Hanya satu token yang dapat dibuat dan memiliki masa berlaku terbatas
• Untuk melakukan operasi pada sumber daya (seperti POST atau PUT ), klien harus memberikan token ini sebagai bagian dari tubuh (atau header?) Dari permintaan. Klien yang tidak memiliki token tidak dapat melakukan operasi ini.

Ini sangat mirip dengan kontrol konkurensi optimis, kecuali bahwa hanya satu klien yang dapat melakukan beberapa operasi (yang mendapatkan token) ... di kebalikan dari "semua klien dapat melakukan semua operasi".

Apakah mekanisme ini kompatibel dengan gaya arsitektur REST? Apakah itu melanggar salah satu kendala? Saya berpikir untuk bertanya pada SO, tetapi ini tampaknya lebih merupakan pertanyaan tingkat tinggi, terkait dengan desain perangkat lunak.

Anda tidak boleh (seperti yang tidak pernah PERNAH) mengunci sumber daya apa pun sambil menunggu interaksi pengguna.

Pada titik tertentu, beberapa pengguna Anda akan pergi untuk akhir pekan yang panjang meninggalkan beberapa catatan penting terkunci.

Ah, tetapi Anda tidak akan membiarkan itu terjadi karena Anda memiliki skema penyelesaian timeout / deadlock yang cerdas; kemudian pada beberapa titik ini akan menjadi sangat salah dan pengguna yang mendapat pesan "widget Anda telah dipesan" yang bagus akan berteriak di help desk meminta untuk mengetahui mengapa widgetnya tidak terkirim.

Kebanyakan orang dapat menangani pesan "maaf pengguna lain baru saja memesan bagian ini".

Menggunakan token sangat umum di API, token ini biasanya dikirim sebagai header dan memiliki siklus hidup yang jelas. Pikirkan misalnya OAuth.

Terlepas dari bahasa atau kerangka kerja pemrograman Anda, API REST serupa.

Saya dapat memikirkan beberapa skenario di mana Anda ingin membatasi konkurensi, dua di antaranya adalah:

1. Banyak klien yang memperbarui sumber daya yang sama seperti baris basis data. Misalnya: dua permintaan bersamaan, satu menghapus catatan dan yang lainnya mencoba memperbarui catatan yang sama. Bergantung pada basis data Anda dan bagaimana Anda mengaturnya, Anda mungkin mendapatkan kunci pada catatan atau operasi yang tidak valid karena data akan berbeda atau tidak akan ada.

2. Pengguna super atau administrator melakukan tindakan khusus dengan API.

Apa yang harus dilakukan dalam kasus ini?

1. Gunakan transaksi dalam database, lajang, kunci dan mekanisme serupa untuk menyinkronkan akses ke sumber daya.

2. Token mungkin berfungsi, saya pikir akan lebih baik jika Anda tidak menyimpan informasi tentang klien, hanya tentang token itu sendiri. Pada satu langkah Anda dapat memvalidasi pengguna dan menetapkan token. Maka cukup validasikan bahwa token itu hidup dan valid. Gunakan token yang dapat didekripsi untuk mendapatkan informasi tambahan. Anda dapat menyimpan jika ini adalah token khusus dan hanya memungkinkan pada satu waktu. Dengan cara ini Anda memvalidasi token, bukan pengguna.

Saya harap ini membantu.

SISA saja terlalu primitif, sungguh. Anda dapat memulai dengan REST, tetapi pada akhirnya, aplikasi kaya Anda akan membutuhkan kueri dengan gabung dan pembaruan dengan transaksi. Setiap pengembang yang mencoba menambahkan hal-hal ini sendiri akan rentan kesalahan dan tidak konsisten. Untungnya, ada standar baru yang disebut OData yang melakukan hal itu. Itu lapisan di atas REST dan menyediakan (1) bahasa permintaan yang memungkinkan untuk bergabung sederhana menggunakan properti navigasi (tanpa harus mengekspos kunci asing), dan, (2) pemrosesan batch yang mencakup set perubahan atom.

Lihat di sini untuk (1) https://stackoverflow.com/a/3921423/471129 , dan,

Lihat di sini dan untuk (2) https://stackoverflow.com/a/21939972/471129