ID ส่วนหลังควรเป็นสาธารณะหรือไม่ใน REST API

ขึ้นอยู่กับสิ่งที่ผู้ชายคนนี้พูดว่า: http://toddfredrich.com/ids-in-rest-api.html

สมมติว่าเขาถูกต้องเกี่ยวกับการใช้ UUID เพื่อระบุทรัพยากร api จากนั้นฉันก็พบปัญหาในการพยายามใช้มันในลักษณะนี้คือ:

class FooEntity {

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

(ระหว่างไคลเอนต์และเซิร์ฟเวอร์ถูกส่งและรับ DTO ไม่ใช่เอนทิตีฐานข้อมูล)

ปัญหาตอนนี้คือidมันไม่มีประโยชน์อย่างที่ฉันไม่ได้ใช้อีกต่อไป ไคลเอนต์ทำการร้องขอด้วยuidเหตุใดฉันจึงรำคาญที่จะจัดการ 2 id ของ จากนั้นเราจะกลับไปสู่จุดเริ่มต้นเดียวกัน หากฉันตั้งค่า UUID เป็นคีย์หลัก ( _id) ฉันจะเปิดเผย ID เบื้องหลังให้กับสาธารณะ

นอกจากนั้นยังมีหัวข้อประสิทธิภาพ ฉันอ่านว่าการจัดทำดัชนีโดย ObjectId นั้นมีประสิทธิภาพมากกว่า UUID มาก

ฉันเปิดเผยรหัสแบ็กเอนด์ต่อสาธารณะ

คุณมีวิธีการอื่นในการระบุตัวตนของคุณเมื่อพวกเขาถูกส่งกลับผ่านการร้องขอ? นั่นถูกต้องตามกฎหมายอย่างสมบูรณ์และปลอดภัยกว่า SSN หรือตัวระบุที่คล้ายกัน นั่นคือสิ่งที่ทอดด์พูดถึง - ทำให้เทคโนโลยีการระบุตัวตนและเอนทิตี้ของเป็นกลางและเขาพูดถูก

หัวข้อประสิทธิภาพ

คุณสามารถเก็บตัวบ่งชี้ทั้งสองได้หาก ObjectId มีประสิทธิภาพมากกว่าจริง ๆ ตามหลักการแล้วการใช้ UUIDs เป็นตัวระบุจะดีกว่าการเพิ่มอัตโนมัติในฐานข้อมูล

ไม่เท่าที่ฐานข้อมูลไปแล้วไม่มีอะไรเกี่ยวกับโครงสร้างภายในที่เปิดเผยกับ API ภายนอก ID ไม่มีสติปัญญา พวกเขาไม่ได้มีลักษณะเฉพาะในโลกแห่งความเป็นจริง ID: 47 มีอยู่ทุกที่ มีเอนทิตีที่คุณสามารถเข้าถึงและอาจจัดการข้อมูลได้ แต่ไม่ว่าฐานข้อมูลนี้จะเก็บทุกอย่างในหนึ่งตารางหรือสิบใช้ ID ที่เพิ่มขึ้นเป็น PK และเกี่ยวข้องกับ FK คุณจะไม่มีทางรู้

หากคุณสามารถ GetUserAccountByID (12345) เพียงแค่ขอให้คนอื่นลองใช้ GetUserAccountByID (12346) แม้ว่ามันจะไม่ทำงานเนื่องจากมาตรการรักษาความปลอดภัยอื่น ๆ อย่าพยายามและไม่พยายามแฮ็กโซเชียลของ บริษัท โดยขอข้อมูลบัญชี: 12346 เว้นแต่คุณจะโทรหา DBA และยินดีที่จะรอ 2 สัปดาห์ ตอบสนอง;)

ดังนั้นสร้าง GUIDs อย่างไรก็ตามที่คุณเห็นว่าเหมาะสมหรือคีย์ธรรมชาติอื่น ๆ เช่นหมายเลขโทรศัพท์หรือที่อยู่อีเมล วางข้อ จำกัด ที่ไม่ซ้ำกันบนฟิลด์ในตารางเพื่อหลีกเลี่ยงการคัดลอกที่คลุมเครือและวางความพยายามในการพยายามรวมข้อมูลบางอย่าง

นี่ไม่ใช่การซ้ำซ้อน ทั้งสองฟิลด์มีวัตถุประสงค์ที่แตกต่างกัน

เกี่ยวกับ id ประสิทธิภาพเทียบกับ UUID ยกเว้นว่าคุณมีการเข้าร่วมหลายครั้งที่เกี่ยวข้องกับหลายตารางแต่ละอันมีการบันทึกนับล้านสิ่งนี้จะไม่แตกต่างกันมากนัก การใช้ UUID ทำให้แอปพลิเคชันของคุณยากขึ้นหากคุณไม่ตรวจสอบ / ใช้งานด้านเซิร์ฟเวอร์:

• รับ [... ] / 1
• รับ [... ] / 2

มันง่ายมากเมื่อใช้ ID ถ้าคุณใช้ UUID แทนมันเป็นทางเลือกที่น้อยกว่าสำหรับ scrapper

ID สามารถมองเห็นเป็นสิ่งที่ใช้ภายในอินสแตนซ์ฐานข้อมูลของแอปพลิเคชันของคุณ มีคำสำคัญสามคำในประโยคนั้น:

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

ตามความชอบส่วนบุคคล: ฉันต้องการมี ID แบบง่ายและ ID ธุรกิจที่ไม่ซ้ำกัน (เมล, ล็อกอิน, ... ) ดังนั้นถ้าฉันต้องแลกเปลี่ยนข้อมูลฉันจะใช้รหัสธุรกิจเนื่องจากระบบเป้าหมายอาจไม่จัดการ UUID แต่เขาจะเป็นไปได้มาก (ไม่เคยพูดไม่เคย ... ) จัดการกับคีย์ธุรกิจที่ไม่ซ้ำกัน