ทำไมการประชุมบอกว่าชื่อตาราง DB ควรเป็นเอกเทศ แต่เป็นพหูพจน์ของทรัพยากร

มันเป็นแบบแผนที่ค่อนข้างกำหนดไว้ว่าอย่างน้อยชื่อตารางฐานข้อมูลใน SQL ควรเป็นแบบเอกพจน์ SELECT * FROM user;ดูคำถามและการอภิปรายนี้

นอกจากนี้ยังมีการประชุมที่ค่อนข้างดีที่ชื่อทรัพยากร RESTful API ควรเป็นพหูพจน์ GET /users/123และPOST /usersดูคนนี้

ใน API ที่ได้รับการสนับสนุนฐานข้อมูลที่ง่ายที่สุดชื่อของทรัพยากรใน URL จะเป็นตารางและองค์ประกอบข้อมูลใน URL และหน่วยงานร้องขอ / ตอบสนองจะจับคู่กับคอลัมน์ในฐานข้อมูลโดยตรง ตามแนวคิดแล้วฉันไม่เห็นความแตกต่างระหว่างการทำงานกับข้อมูลผ่าน API เชิงทฤษฎีนี้กับการทำงานบน SQL โดยตรง และด้วยเหตุนี้ความแตกต่างในการตั้งชื่อข้อตกลงระหว่างuserและusersไม่สมเหตุสมผลกับฉัน

ความแตกต่างในการทำให้เป็นพหูพจน์เป็นอย่างไรเมื่อแนวคิด REST API และ SQL กำลังทำสิ่งเดียวกัน

ข้อมูลจำเพาะ REST (ระดับใดก็ตามที่คุณต้องการไปด้วย) ไม่ได้ออกแบบเป็นการเข้าถึงฐานข้อมูล กำลังพยายามนำมาตรฐานไปสู่การเข้าถึง API ข้อตกลง SQL ที่กล่าวถึง (ไม่ว่าคุณต้องการใช้หรือไม่ก็ตาม) ไม่ได้ถูกออกแบบโดยคำนึงถึงการเข้าถึง API พวกเขามีไว้สำหรับการเขียนแบบสอบถาม SQL

ดังนั้นปัญหาในการแกะที่นี่คือความเข้าใจในแนวคิดที่ API แมปกับฐานข้อมูลโดยตรง เราสามารถหานี้อธิบายว่าเป็นรูปแบบการป้องกันอย่างน้อยไกลกลับถึง 2009

เหตุผลหลักที่ว่านี้ไม่ดี? รหัสอธิบายว่า "การดำเนินการนี้มีผลต่อข้อมูลของฉันอย่างไร" กลายเป็นรหัสลูกค้า

สิ่งนี้มีผลกระทบที่แย่มากต่อ API (ไม่ใช่รายการที่ครบถ้วนสมบูรณ์)

มันทำให้การรวมกับ API เป็นเรื่องยาก

ฉันจินตนาการถึงขั้นตอนในการสร้างผู้ใช้ใหม่ที่มีเอกสารดังนี้:

1. POST /users { .. }
2. POST /usersettings { .. } ด้วยค่าเริ่มต้นบางอย่าง
3. POST /confirmemails { .. }

แต่คุณจะจัดการกับความล้มเหลวของขั้นตอน # 2 ได้อย่างไร สำเนาพาสต้าแบบลอจิกการจัดการตรรกะนี้มีจำนวนเท่ากันสำหรับลูกค้ารายอื่นของ API ของคุณหรือไม่

การดำเนินการข้อมูลเหล่านี้มักจะง่ายต่อการจัดลำดับในฝั่งเซิร์ฟเวอร์ในขณะที่การเริ่มต้นจากลูกค้าเป็นการดำเนินการเดียว เช่นPOST /newusersetupเช่นDBAs อาจรับรู้ว่านี่เป็นขั้นตอนการจัดเก็บไว้ แต่การทำงานของ API อาจมีผลกระทบมากกว่าแค่ฐานข้อมูล

การรักษาความปลอดภัยของ API จะกลายเป็นหลุมดำแห่งความสิ้นหวัง

สมมติว่าคุณต้องรวมสองบัญชีผู้ใช้

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

คุณจะตั้งค่าการอนุญาตของผู้ใช้เพื่ออนุญาตคุณลักษณะการผสานในขณะที่ไม่อนุญาตให้ลบผู้ใช้อย่างไร กำลังลบผู้ใช้แม้จะแสดงอย่างเป็นธรรมโดยDELETE /users/1เมื่อ/usersettingsมีอยู่ด้วยหรือไม่?

การทำงานของ API ควรถูกมองว่าเป็นการดำเนินงานระดับสูงกว่าฐานข้อมูลซึ่งอาจทำให้เกิดการเปลี่ยนแปลงหลายอย่างในระบบ

การบำรุงรักษายากขึ้น

... เนื่องจากลูกค้าของคุณขึ้นอยู่กับโครงสร้างฐานข้อมูลของคุณ

จากประสบการณ์ของฉันกับสถานการณ์นี้:

• คุณไม่สามารถเปลี่ยนชื่อหรือลบตาราง / คอลัมน์ที่มีอยู่ แม้ว่าจะตั้งชื่อไม่ถูกต้องสำหรับฟังก์ชั่นของพวกเขาหรือไม่ได้ใช้อีกต่อไป ลูกค้าจะแตก
• คุณลักษณะใหม่ไม่สามารถเปลี่ยนโครงสร้างข้อมูลที่มีอยู่ได้ดังนั้นข้อมูลและฟังก์ชันการทำงานมักจะถูกแยกออกจากกันแม้ว่ามันจะเป็นคุณสมบัติแบบองค์รวมที่เป็นองค์รวมก็ตาม
• รหัสฐานค่อยๆเข้าใจได้ยากขึ้นเนื่องจากการแยกส่วนชื่อที่สับสนและสัมภาระที่เหลือซึ่งไม่สามารถนำออกได้อย่างปลอดภัย
• การเปลี่ยนแปลงทั้งหมดเพียงเล็กน้อยนั้นมีความเสี่ยงและใช้เวลานานขึ้น
• ระบบหยุดทำงานและถูกแทนที่ในที่สุด

อย่าเปิดเผยโครงสร้างฐานข้อมูลของคุณโดยตรงไปยังลูกค้า ... โดยเฉพาะลูกค้าที่คุณไม่สามารถควบคุมพัฒนาการได้ ใช้ API เพื่อ จำกัด ลูกค้าให้แคบลงเพื่อการทำงานที่ถูกต้อง

ดังนั้นหากคุณใช้ API เป็นเพียงส่วนต่อประสานเข้ากับฐานข้อมูลพหูพจน์เป็นสิ่งที่คุณกังวลน้อยที่สุด สำหรับนอกเหนือจากการทดลองทิ้งฉันขอแนะนำให้ใช้เวลาพิจารณาการดำเนินงานระดับสูงกว่าที่ API ควรเป็นตัวแทน และเมื่อคุณดูอย่างนั้นจะไม่มีความขัดแย้งระหว่างชื่อเอนทิตีแบบหลายส่วนของ API กับชื่อเอนทิตี SQL เอกพจน์ พวกเขาอยู่ที่นั่นด้วยเหตุผลที่แตกต่างกัน

REST API และ SQL ไม่ใช่ "ทำสิ่งเดียวกัน"

OP ถาม:

ความแตกต่างในการทำให้เป็นพหูพจน์เป็นอย่างไรเมื่อแนวคิด REST API และ SQL กำลังทำสิ่งเดียวกัน

มันอาจจะปรากฏขึ้นมาว่าอินเตอร์เฟส RESTful และตาราง SQL "กำลังทำสิ่งเดียวกัน" แต่สุขอนามัยการเขียนโปรแกรมที่ดีบอกเราว่ามีเลเยอร์กลางที่เป็นสื่อกลางระหว่าง REST API และฐานข้อมูลเสมอ การละเว้นจุดนี้คือการหลงทางจากเส้นทางสู่การตรัสรู้ของซอฟต์แวร์! :)

ดังนั้น RESTful APIs และตาราง SQL สามารถทำตามระเบียบการตั้งชื่อของพวกเขาได้อย่างมีความสุข