มันเป็นการปฏิบัติที่ไม่ถูกต้องหรือไม่สำหรับคำนิยามออบเจ็กต์ API ที่มีรหัสอ้างอิงบุคคลที่สามเป็นคุณสมบัติหรือไม่


9

แบบนี้:

Campaign:
type: object
properties:
  id: 
    type: string
    description: "A GUID identifier"
  referenceId:
    type: string
    description: "A consumers identifier they have used to map their own systems logic to this object."
  name:
    type: string
    description: "'Great Campaign 2017' as an example"

ผมกังวลเกี่ยวกับreferenceid

โดเมนระบบเป็นแพลตฟอร์มที่รวมเข้ากับบุคคลที่สามได้หลายวิธีผ่านการส่งออกข้อมูลและการนำเข้ารูปแบบต่างๆ (xml, excel) เป็นผู้ใหญ่พอที่จะอนุญาตให้บุคคลที่ 3 รวมกับระบบของเราผ่าน API และการออกแบบของ API นี้เป็นสิ่งที่แจ้งคำถามนี้

เรามีวัตถุเป็นแคมเปญซึ่งมีรหัสที่สามารถใช้ในการระบุและดึงทรัพยากร ผู้บริโภคของ API ของเราอาจมีรหัสอ้างอิงของตนเองกับสิ่งที่พวกเขาพิจารณาว่าเป็นแคมเปญภายในโดเมนของตน

มีวัตถุอื่น ๆ ในระบบของเราที่มีเขตข้อมูลอ้างอิงบุคคลที่สามเช่นนี้และเป็นที่คาดหวังจากผู้บริโภคที่มีอยู่ของเรา อย่างไรก็ตามฉันกังวลว่ามันเป็นภาระของการทำแผนที่กับเราและเราไม่ทราบว่าสิ่งที่อ้างอิงนี้คืออะไร (หมายเลข, ข้อความ, json?) และมันเพิ่มคุณสมบัติที่สับสนอีกอย่างสำหรับ API สำหรับผู้บริโภคใหม่

ถือว่าเป็นการปฏิบัติที่ไม่ดีหรือการออกแบบที่ไม่ดีเพื่ออนุญาตให้มีเขตข้อมูลรหัสอ้างอิงบุคคลที่สามในคำจำกัดความของวัตถุสาธารณะสำหรับ API หรือไม่

คำตอบ:


13

นี่ไม่ใช่ปัญหา; มันเป็นความจำเป็น การขาดข้อมูลนี้จะเป็นปัญหาสำหรับการรวมเข้ากับระบบลูกค้า

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

การออกแบบที่ตรงไปตรงมาที่สุดเพื่อหลีกเลี่ยงความกังวลใด ๆ ก็คือการไม่รับผิดชอบต่อสนาม เพียงแค่ให้มันและให้ลูกค้าใช้หากพวกเขาเลือก อย่าตรวจสอบความถูกต้องหรือใช้งานในตรรกะของคุณเอง (แม้ว่าจะมีฟังก์ชั่นการใช้งานที่ดูดี) อาจทำให้คุณยุ่งเหยิงกับปัญหาการออกแบบหรือข้อบกพร่องของลูกค้า แน่นอนว่าอย่าใช้ค่านี้เป็น ID ภายใน โครงสร้างข้อมูลที่คุณแสดงให้เห็นว่านี่เป็นวิธีการที่คุณใช้

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

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


ขอบคุณสำหรับคำแนะนำของคุณที่จะเปลี่ยนชื่อจาก Id เป็นอย่างอื่น ฉันชอบรหัสอ้างอิง ฉันทำเครื่องหมายว่าเป็นฟิลด์ตัวเลือกที่มีข้อ จำกัด เกี่ยวกับความยาวสตริงและนั่นคือทั้งหมด ฉันยังคงมีความกังวลว่ารูปแบบนี้จะทำงานผ่านวัตถุอื่น ๆ ในระบบของเราและต้องการหลีกเลี่ยงวัตถุย่อยใด ๆ ที่ต้องการรหัสอ้างอิงของตัวเอง แต่นั่นคือการตัดสินใจออกแบบ ขอบคุณสำหรับตัวอย่างกรณีการใช้งานด้วย คำตอบที่ยอดเยี่ยม
jezpez

1

ฉันไม่คิดว่าจะมีวิธีปฏิบัติที่ดีที่สุดเกี่ยวกับเรื่องนี้ referenceIdจำเป็นต้องมีการถือครองทึบแสงในระบบของคุณหรือไม่ขึ้นอยู่กับความสัมพันธ์ของคุณกับลูกค้าบุคคลที่สาม

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

แต่อีกครั้งถ้านี่เป็นส่วนหนึ่งของสัญญาระหว่างคุณกับพวกเขาคุณต้องรักษาส่วนหนึ่งของการต่อรองและจัดหาทรัพย์สินที่ทึบแสงนั้น


0

การอ้างอิงบุคคลที่สามเป็นความคิดที่ดีที่ข้อมูลเฉพาะใด ๆ ที่เป็นของบุคคลที่สามและคุณเป็นเพียงผู้ดูแล

นอกจากนี้ยังเป็นประโยชน์อย่างมากในการสร้างกลไกสำหรับ idempotency สำหรับการเขียน / อัปเดต

ดังนั้นในส่วนแรกสิ่งสำคัญคือต้องสร้างสัญญารอบการอ้างอิงนั้น หากเป็นเอกลักษณ์ให้บังคับใช้ด้วยตรรกะและคำเตือน / รหัสข้อผิดพลาดที่เหมาะสมเมื่อเขียน

เพื่อความยืดหยุ่นเป็นเรื่องปกติที่การอ้างอิงจะเป็นสตริงเอง

นอกจากนี้ฉันขอแนะนำให้ใช้ตัวระบุภายในเช่นเดียวกับที่คุณทำดังนั้นโมเดลข้อมูลของฉันจึงไม่พึ่งพารูปแบบเฉพาะสำหรับคีย์

การอ้างอิงภายในทั้งหมดจะใช้ตัวระบุภายใน นอกจากนี้ยังเหมาะกับโลกแห่ง REST ซึ่งอาจทำสิ่งต่าง ๆ เช่นใช้ id ของอินไลน์กับ URL ดูจุดถัดไป

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

การใช้ idempotency ซ้ำโดยใช้ตัวระบุภายนอกที่ไม่ซ้ำกันคุณสามารถตรวจสอบความพยายามซ้ำ ๆ เพื่อสร้างระเบียนโดยหลีกเลี่ยงข้อผิดพลาด "double write" สำหรับฉันนั่นเป็นเหตุผลที่ชัดเจนที่ไม่เพียง แต่สนับสนุนแนวคิดเท่านั้น แต่ยังสามารถบังคับได้ถ้าคุณทำได้

ความล้มเหลวที่คุณสามารถใช้รหัสธุรกรรม / รหัสข้อความของการดำเนินการได้ แต่อยู่นอกขอบเขตของคำถาม


1
ฉันจะไม่แนะนำการบังคับใช้เอกลักษณ์หรือสิ่งอื่นใดในเขตข้อมูล แม้ว่าในทางทฤษฎีแล้วมันควรจะไม่ซ้ำกัน เพราะถ้าระบบของลูกค้ามีปัญหาคุณภาพข้อมูลหรือพวกเขาเปลี่ยนข้อกำหนดมันก็จะกลายเป็นปัญหาของคุณ ดีที่สุดที่จะไม่รับผิดชอบแทนที่จะเป็นครึ่งทางที่คุณไม่สามารถควบคุมได้ แต่จะถูกเผา

แน่นอนมันขึ้นอยู่กับสัญญา อย่างที่ฉันและคอนสแตนตินพูด เอกลักษณ์สามารถช่วยด้วย idempotency / การหลีกเลี่ยงซ้ำ หากลูกค้าของคุณกำลังส่งขยะคุณก็ไม่ต้องพึ่งพามันอย่างแน่นอน ฉันมักจะทำงานกับระบบธนาคารดังนั้นคุณสามารถจินตนาการได้ว่าความปลอดภัยมีความสำคัญมากกว่าความสะดวกสบาย
emperorz
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.