Haruskah ID backend bersifat publik atau tidak pada REST API?

Berdasarkan apa yang dikatakan orang ini: http://toddfredrich.com/ids-in-rest-api.html

Anggaplah dia benar tentang menggunakan UUID untuk mengidentifikasi sumber api. Lalu saya mengalami kesulitan mencoba menerapkannya seperti ini, ini adalah:

class FooEntity {

    final String id = null;  //auto-generated by my backend (mongodb), not shared
    final UUID uid = UUID.randomUUID();  //the resource id
}

(Antara klien dan server, dikirim dan diterima DTO, bukan entitas basis data.)

Masalahnya sekarang adalah itu idtidak berguna karena saya tidak menggunakannya lagi. Klien mengajukan permintaan, uidjadi mengapa saya repot-repot menangani 2 id? Kemudian kita kembali ke masalah yang sama di awal. Jika saya menetapkan UUID sebagai kunci utama ( _id) maka saya mengekspos backend id kepada publik.

Selain itu, ada topik efisiensi. Saya telah membaca bahwa pengindeksan oleh ObjectId jauh lebih efisien daripada UUID.

Saya mengekspos id backend kepada publik

Apa cara lain yang Anda miliki untuk mengidentifikasi entitas Anda ketika mereka dikembalikan melalui permintaan? Itu sangat sah dan lebih aman daripada SSN atau pengidentifikasi serupa. Itulah yang Todd bicarakan - membuat teknologi identifikasi dan entitas netral dan dia benar.

Topik efisiensi

Anda dapat menyimpan kedua pengidentifikasi jika ObjectId benar-benar jauh lebih efisien. Secara teoritis selalu lebih baik untuk menggunakan UUID untuk pengidentifikasi daripada penambahan database otomatis.

Tidak, sejauh database berjalan, tidak ada apapun tentang struktur internal yang terkena API luar. ID tidak memiliki kecerdasan. Mereka bahkan tidak unik di dunia nyata. ID: 47 ada di mana-mana. Ada entitas yang Anda punya akses dan mungkin dapat memanipulasi data, tetapi apakah database ini menyimpan semuanya dalam satu atau sepuluh tabel, menggunakan ID tambahan sebagai PK dan berhubungan dengan FK, Anda tidak akan pernah tahu.

Jika Anda dapat GetUserAccountByID (12345) hanya meminta seseorang untuk mencoba GetUserAccountByID (12346). Walaupun itu tidak akan berhasil karena langkah-langkah keamanan lainnya, jangan coba-coba dan jangan coba-coba peretasan sosial perusahaan dengan meminta informasi pada Akun: 12346. Kecuali Anda menelepon DBA dan bersedia menunggu 2 minggu untuk tanggapan;)

Jadi buat GUIDs sesuai keinginan Anda atau kunci alami lainnya seperti nomor telepon atau alamat email. Letakkan batasan unik pada bidang di tabel untuk menghindari beberapa upaya penyalinan dan rekat yang tidak jelas dalam beberapa upaya penggabungan data.

Ini tidak berlebihan. Kedua bidang memiliki tujuan berbeda.

Tentang efisiensi id vs UUID, kecuali jika Anda memiliki beberapa gabungan yang melibatkan beberapa tabel yang masing-masing memiliki jutaan catatan, ini tidak akan banyak bedanya. Menggunakan UUID membuat aplikasi Anda jauh lebih sulit untuk dihapus jika Anda tidak memeriksa / mendaftar langsung di sisi server .:

• DAPATKAN [...] / 1
• DAPATKAN [...] / 2

Sangat mudah saat menggunakan ID, jika Anda menggunakan UUID sebagai gantinya, itu adalah satu pilihan yang lebih sedikit untuk seorang pencakar.

ID dapat dilihat sebagai sesuatu yang internal ke instance database aplikasi Anda. Ada tiga kata penting dalam kalimat itu:

• Aplikasi: karena ini adalah model Anda, kemungkinan tabel Anda hanya digunakan oleh aplikasi itu
• Database: Jika beberapa aplikasi menggunakannya terhadap database yang sama, Anda akan baik-baik saja
• Instance (dari database): jika Anda memiliki sistem terdistribusi, id akan bertentangan satu sama lain, dan mereka tidak akan berarti untuk sistem / aplikasi lain yang tidak menggunakan instance database Anda. UUID adalah solusi untuk kasus khusus itu.

Pada preferensi pribadi: Saya lebih suka memiliki ID sederhana dan ID bisnis unik (mail, login, ...). Jadi jika saya harus bertukar data, saya akan menggunakan ID bisnis, karena sistem target mungkin tidak menangani UUID, tetapi dia kemungkinan besar (tidak pernah mengatakan tidak pernah ...) menangani dengan baik kunci bisnis yang unik.