Mengapa konvensi mengatakan nama tabel DB harus tunggal tetapi sumber daya TETAP jamak?

Ini adalah konvensi yang cukup mapan bahwa nama tabel database, setidaknya dalam SQL, harus tunggal. SELECT * FROM user;Lihat pertanyaan dan diskusi ini .

Ini juga merupakan konvensi yang cukup mapan bahwa nama sumber daya RESTful API harus jamak. GET /users/123dan POST /usersLihat yang ini .

Dalam API yang didukung database paling sederhana, nama sumber daya di URL akan menjadi tabel, dan elemen data dalam URL dan badan permintaan / respons akan memetakan langsung ke kolom di DB. Secara konseptual, saya tidak melihat perbedaan antara beroperasi pada data melalui API teoretis ini dibandingkan beroperasi secara langsung melalui SQL. Dan karena itu, perbedaan dalam konvensi penamaan antara userdan userstidak masuk akal bagi saya.

Bagaimana perbedaan dalam pluralisasi dibenarkan ketika, secara konseptual, REST API dan SQL melakukan hal yang sama?

rest api sql conventions naming-standards smitelli
sumber

Tidak ada konvensi tunggal dalam penamaan tabel DB atau penamaan sumber daya yang tenang yang diikuti semua orang. Sebaliknya, mungkin ada banyak konvensi. Tidak mengherankan bahwa beberapa mungkin berbenturan.

Eric King

Tidak ada konvensi yang ditetapkan seperti itu. Saya selalu menggunakan nama tabel jamak. pengguna , akun , dll, karena mereka memegang lebih dari satu hal.

GrandmasterB

@GrandmasterB Konvensi ini memang ada dan berasal dari model relasional Codd di mana "hubungan" (yang menjadi tabel, bukan membingungkan dengan hubungan) memiliki nama tunggal karena relasi adalah daftar hal-hal yang bukan beberapa daftar hal. Setiap relasi adalah satu daftar. Model hubungan entitas domain. Nama entitas tunggal dalam model relasional Codd. Ada banyak literatur tentang itu untuk mengatakan itu tidak ada. Tetapi sangat baik bagi Anda untuk menggunakan nama jamak jika Anda mau.

Tulains Córdova

@ user61852 Ada orang yang dapat menggunakannya dengan konvensi. Tetapi tidak berarti konvensi industri yang diikuti secara luas seperti yang disajikan dalam pertanyaan ini dengan cara, katakanlah, bahwa camelCase atau MarkDown adalah.

GrandmasterB

Juga perlu diingat bahwa REST bukan protokol akses database. Tidak ada alasan bahwa konvensi penamaan DB (yang pernah Anda ikuti) dan konvensi penamaan URL (yang pernah Anda ikuti) harus sama, mereka tidak ada hubungannya satu sama lain. Dua domain yang sangat berbeda. Tidak lagi masuk akal untuk merenungkan mengapa basis data menggunakan singular dan URL menggunakan bentuk jamak daripada merenungkan mengapa basis data menggunakan tunggal tetapi admin sistem saya menamai direktori sistem file-nya jamak. Kerangka kerja web yang dirancang dengan buruk membuat orang berpikir REST adalah sesuatu yang berkaitan dengan akses DB, tetapi tidak.

Cormac Mulhall

Jawaban:

Spesifikasi REST (level apa pun yang ingin Anda tuju) tidak dirancang sebagai akses basis data. Ia mencoba membawa standardisasi ke akses API. Konvensi SQL yang disebutkan (apakah Anda ingin menggunakannya atau tidak) tidak dirancang dengan mempertimbangkan akses API. Mereka untuk menulis kueri SQL.

Jadi masalah yang harus dibongkar di sini adalah pemahaman konseptual bahwa API memetakan langsung ke database. Kita dapat menemukan ini digambarkan sebagai anti-pola setidaknya sejak 2009 .

Alasan utama ini buruk? Kode yang menjelaskan "bagaimana operasi ini mempengaruhi data saya?" menjadi kode klien .

Ini memiliki beberapa efek yang sangat buruk pada API. (bukan daftar lengkap)

Itu membuat pengintegrasian dengan API sulit

Saya membayangkan langkah-langkah untuk membuat pengguna baru yang didokumentasikan sebagai sesuatu seperti ini:

POST /users { .. }
POST /usersettings { .. } dengan beberapa nilai default
POST /confirmemails { .. }

Tetapi bagaimana Anda menangani kegagalan langkah # 2? Berapa kali logika penanganan yang sama ini disalin-tempel ke klien lain dari API Anda?

Operasi data ini sering lebih mudah untuk urutan di sisi server, sementara diprakarsai dari klien sebagai operasi tunggal. Misalnya POST /newusersetup. DBA mungkin mengenali ini sebagai prosedur tersimpan, tetapi operasi API mungkin memiliki efek lebih dari sekadar basis data.

Mengamankan API menjadi lubang hitam keputusasaan

Katakanlah Anda perlu menggabungkan dua akun pengguna.

GET /users/1
PUT /users/2 { .. }
DELETE /users/1

Bagaimana Anda akan mengatur izin pengguna untuk mengizinkan fitur penggabungan sementara tidak mengizinkan penghapusan pengguna? Apakah menghapus pengguna bahkan diwakili dengan adil DELETE /users/1ketika /usersettingsjuga ada?

Operasi API harus dipandang sebagai operasi tingkat yang lebih tinggi (daripada basis data) yang dapat menyebabkan banyak perubahan dalam sistem.

Perawatan menjadi lebih sulit

... karena klien Anda bergantung pada struktur basis data Anda.

Berdasarkan pengalaman saya dengan skenario ini:

Anda tidak dapat mengganti nama atau menghapus tabel / kolom yang ada. Bahkan ketika nama mereka salah untuk fungsinya atau tidak lagi digunakan. Klien akan putus.
Fitur-fitur baru tidak dapat mengubah struktur data yang ada, sehingga data dan fungsinya seringkali dipisahkan secara artifisial bahkan ketika itu secara holistik memiliki fitur yang ada.
Basis kode secara bertahap menjadi lebih sulit untuk dipahami karena fragmentasi, nama yang membingungkan, dan bagasi sisa yang tidak dapat dihapus dengan aman.
Semua kecuali perubahan sepele menjadi semakin berisiko dan memakan waktu.
Sistem mandek dan akhirnya diganti.

Jangan memaparkan struktur basis data Anda secara langsung ke klien ... terutama klien yang tidak Anda miliki kendali perkembangannya. Gunakan API untuk mempersempit klien ke operasi yang sah saja.

Jadi, jika Anda menggunakan API hanya sebagai antarmuka langsung ke database, pluralisasi adalah yang paling tidak Anda khawatirkan. Untuk selain percobaan membuang-buang, saya akan menyarankan menghabiskan waktu menentukan operasi tingkat tinggi yang harus diwakili oleh API. Dan ketika Anda melihatnya dengan cara itu, tidak ada konflik antara nama entitas API yang jamak dan nama entitas SQL tunggal. Mereka ada di sana karena berbagai alasan.

Kasey Speakman
sumber

Menjawab pertanyaan yang berbeda. OP tidak menyiratkan hubungan langsung antara entitas API dan DB, hanya keberadaan beberapa entitas dalam kedua konteks.

Basilevs

Jangan ragu untuk mengirim jawaban atas pertanyaan yang menurut Anda ditanyakan.

Kasey Speakman

@ Basilevs Sebenarnya saya pikir ini menjawab pertanyaan. Kadang-kadang jawaban mungkin muncul tidak langsung ketika pertanyaan dibingkai di sekitar asumsi yang salah. The "Kehadiran beberapa entitas baik dalam konteks" menyiratkan mereka adalah entitas yang sama, yang menyiratkan 1-1 korespondensi antara beberapa dan bukan orang lain. Korespondensi semacam API atas model data yang kompleks menyiratkan desain yang cacat.

Aluan Haddad

Di antara ini adalah banyak alasan saya berhenti menggunakan Spring Data Rest.

Sebastiaan van den Broek

REST API dan SQL TIDAK "melakukan hal yang sama"

OP bertanya:

Bagaimana perbedaan dalam pluralisasi dibenarkan ketika, secara konseptual, REST API dan SQL melakukan hal yang sama?

Ah, tapi belalang, mungkin tampak bahwa antarmuka RESTful dan tabel SQL "melakukan hal yang sama", tetapi kebersihan pemrograman yang baik memberi tahu kita bahwa selalu ada lapisan perantara yang memediasi antara API REST dan basis data. Mengabaikan hal ini berarti menyimpang dari jalan menuju pencerahan perangkat lunak! :)

Jadi RESTful APIs dan SQL tables dengan senang hati dapat mengikuti konvensi penamaan idiomatik mereka sendiri, yang didokumentasikan dengan baik dan didiskusikan secara menyeluruh di tempat lain.

fearless_fool
sumber