เครื่องมือสำหรับนักพัฒนา · ตัวสร้าง UUID
คีย์ Idempotency: การใช้ UUID ที่ไคลเอ็นต์สร้างขึ้นเพื่อทำให้การลองใหม่ปลอดภัย
· เหตุใดจึงสำคัญ
uuid การเข้ารหัส เบราว์เซอร์-apis
การหมดเวลาของคำขอชำระเงินทำให้คุณไม่แน่ใจว่าคำขอดังกล่าวดำเนินการเสร็จสิ้นหรือไม่ คีย์ Idempotency ช่วยให้คุณลองอีกครั้งได้อย่างปลอดภัย และ CSPRNG ที่สร้าง UUID นั้นเป็นคีย์ทั่วไป โพสต์นี้จะอธิบายรูปแบบตั้งแต่ต้นจนจบ
การหมดเวลาที่อาจเรียกเก็บเงินจากลูกค้าสองครั้ง — มีคีย์ idempotency ของโหมดความล้มเหลวที่ต้องแก้ไข
การหมดเวลาระหว่างคำขอชำระเงินทำให้เกิดความไม่แน่นอนอย่างแท้จริงสำหรับลูกค้าและระบบ ลูกค้า HTTP ของคุณยกเลิกการรอการตอบกลับ แต่เซิร์ฟเวอร์การชำระเงินอาจประมวลผลธุรกรรมก่อนที่การเชื่อมต่อจะปิดหรือหมดเวลา If you retry the same request, you might charge the customer twice. If you do not retry, the payment never completes. ระบบการชำระเงินล้มเหลวสู่จุดกึ่งกลางที่ไม่มีความสุข: เงินของลูกค้าอาจหมด อาจมาถึงพรุ่งนี้ อาจติดอยู่ในคิวดำเนินการ หรืออาจไม่ออกจากบัญชีเลย This ambiguity is unacceptable for financial systems.
วิธีการทำงานของคีย์ idempotency — เซิร์ฟเวอร์จัดเก็บการตอบสนองแรกไว้ใต้คีย์และเล่นซ้ำเพื่อทำซ้ำ
คีย์ idempotency แก้ปัญหานี้ด้วยการทำให้การลองใหม่ปลอดภัยและให้ผลแน่นอน ไคลเอนต์สร้างคีย์ที่ไม่ซ้ำสำหรับแต่ละเจตนา เช่น การชำระเงิน การโอน หรือการเรียกเก็บเงิน แล้วส่งคีย์นั้นไปกับทุกคำขอ เซิร์ฟเวอร์ประมวลผลการชำระเงิน แคชการตอบกลับไว้ใต้คีย์ และจัดเก็บทั้งคีย์กับผลลัพธ์ หากได้รับคีย์เดิมอีกครั้งภายในช่วงเวลาที่เก็บข้อมูล เซิร์ฟเวอร์จะส่งการตอบกลับที่แคชไว้โดยไม่ประมวลผลการชำระเงินซ้ำ ลูกค้าจึงลองใหม่ได้อย่างมั่นใจ เพราะคีย์เดิมจะให้ผลเดิมเสมอไม่ว่าจะส่งกี่ครั้ง รูปแบบนี้ขจัดความกำกวมและทำให้ตรรกะการลองใหม่ปลอดภัย
สร้างก่อนความพยายามครั้งแรก - เหตุใดจึงต้องมีคีย์ก่อนที่คำขอจะออกและนำมาใช้ซ้ำทุกคำเมื่อลองอีกครั้ง
รูปแบบนี้เก่ากว่าข้อกำหนด HTTP สมัยใหม่ แต่มีความโดดเด่นในด้านการชำระเงินหลังจากการสูญเสียทางการเงินอย่างกว้างขวางและการร้องเรียนจากลูกค้าจากการเรียกเก็บเงินซ้ำซ้อน Every payment API and many web service APIs now support idempotency keys. CSPRNG ที่สร้าง UUID เป็นตัวเลือกที่เป็นธรรมชาติสำหรับคีย์ เนื่องจากคาดเดาไม่ได้ มีเอกลักษณ์เฉพาะตัวโดยไม่มีการประสานงานใดๆ ระหว่างไคลเอนต์ และไม่จำเป็นต้องมีการจัดสรรฝั่งเซิร์ฟเวอร์หรืออำนาจจากส่วนกลาง The client generates it before the first attempt, reuses it verbatim on every retry and receives the same response every time. ไม่จำเป็นต้องมีสถานะฝั่งเซิร์ฟเวอร์เพื่อประสานการสร้างคีย์
เหตุใดจึงสุ่ม UUID และไม่ใช่ตัวนับหรือเพย์โหลดแฮช — ความเป็นเอกลักษณ์ที่ไม่มีการประสานงานและไม่มีการนำมาใช้ซ้ำโดยไม่ตั้งใจข้ามเจตนา
คีย์ต้องมีอยู่ก่อนที่คำขอจะออกจากไคลเอ็นต์ เนื่องจากการสร้างคีย์เมื่อลองใหม่นั้นสายเกินไปที่จะรับประกันความเป็นค่าเดิม หากคำขอแรกสำเร็จและเรียกเก็บเงินจากลูกค้า การสร้างคีย์ใหม่เมื่อลองอีกครั้งจะปกปิดปัญหาและเรียกเก็บเงินอีกครั้ง ไคลเอนต์จะต้องยอมรับคีย์ก่อนที่จะพยายามครั้งแรก เก็บไว้ในหน่วยความจำหรือที่เก็บข้อมูลถาวร และใช้คีย์เดิมนั้นซ้ำหากจำเป็นต้องหมดเวลาหรือลองใหม่อีกครั้ง สำหรับการทดสอบ API ด้วยตนเอง ตัวสร้าง ToolAcre จะสร้างคีย์ที่คุณสามารถวางลงใน curl หรือไคลเอนต์ REST คัดลอกและนำมาใช้ซ้ำในคำขอหลายรายการเพื่อทดสอบพฤติกรรมของค่าเดิม
ขอบเขตและอายุการใช้งาน — คีย์ต่อการดำเนินการ ต่อบัญชี และระยะเวลาที่เซิร์ฟเวอร์ควรจดจำ
Why a UUID rather than a hash or sequential counter for idempotency keys? A hash of the request payload seems intuitive—identical payloads get identical hashes and thus identical keys. แต่แฮชนั้นอ่อนแอสำหรับกรณีการใช้งานนี้ เนื่องจากคำขอที่เกือบจะเหมือนกันสองคำขอที่มีจำนวนต่างกัน ผู้รับที่แตกต่างกัน หรือพารามิเตอร์ที่แตกต่างกันทำให้เกิดแฮชที่แตกต่างกันโดยสิ้นเชิง ดังนั้นจึงสร้างค่าใช้จ่ายแยกกัน ซึ่งถูกต้อง แต่ไม่ได้ให้การป้องกันทั้งหมดที่จำเป็น ตัวนับตามลำดับจำเป็นต้องมีการประสานงานและสถานะแบบกระจาย: หากไคลเอนต์ทั้งสองสร้างคีย์ที่อิงตัวนับบนโครงสร้างพื้นฐานของคุณ ตัวนับของพวกเขาอาจชนกัน UUID ไม่จำเป็นต้องมีหน่วยงานกลาง ไม่สามารถคาดเดาได้ และไม่น่าจะเกิดการชนกันโดยบังเอิญทั่วทั้งอินเทอร์เน็ตตลอดเวลา
ตัวอย่างการทำงาน — ลำดับการลองใหม่โดยใช้คีย์เดียวกัน โดยแสดงว่าไคลเอนต์ส่งอะไรและเซิร์ฟเวอร์ส่งคืนอะไรในแต่ละครั้ง
The server-side implementation stores responses under keys and returns cached responses on repeats. ความซับซ้อนอยู่ที่การตัดสินใจเลือกคำถามในการปฏิบัติงาน ได้แก่ ระยะเวลาการเก็บรักษาว่าจะจดจำคีย์ได้นานแค่ไหน ขนาดแคช จำนวนคีย์ที่ต้องจดจำ การล็อกวิธีป้องกันคำขอสองรายการที่เกิดขึ้นพร้อมกันด้วยคีย์เดียวกันจากการประมวลผลการชำระเงินสองครั้ง และการล้างข้อมูลเมื่อลืมคีย์ คำถามเหล่านี้เป็นคำถามเกี่ยวกับการจัดเก็บและความน่าเชื่อถือที่อยู่นอกขอบเขตของตัวสร้าง UUID The client's job is to generate a good key and reuse it on retries; the server's job is to implement the cache correctly and durably.
สิ่งนี้ไม่ครอบคลุม — พื้นที่เก็บข้อมูลฝั่งเซิร์ฟเวอร์และการล็อคที่จำเป็นในการใช้รูปแบบ ซึ่งเป็นการออกแบบที่แยกต่างหาก
A worked example shows a typical sequence in practice. A mobile app needs to transfer money to a friend using an API that supports idempotency. ก่อนที่จะส่งคำขอ แอปจะสร้าง UUID โดยใช้ไลบรารี crypto ในเครื่องหรือดึงข้อมูลจากตัวสร้าง ToolAcre เพื่อการทดสอบ: 3fa85f64-5717-4562-b3fc-2c963f66afa6 แอปส่งคำขอ POST ไปยัง /transfers ด้วยเนื้อหา JSON และ HTTP ส่วนหัว Idempotency-Key: 3fa85f64-5717-4562-b3fc-2c963f66afa6 เซิร์ฟเวอร์ประมวลผลการถ่ายโอน โดยจัดเก็บ 3fa85f64-5717-4562-b3fc-2c963f66afa6 → {status: "success", transferId: "xfer-12345"} ไว้ในแคช และส่งคืนการตอบกลับ 200 พร้อมผลลัพธ์
ประเด็นสำคัญ: หนึ่งเจตนา หนึ่งคีย์ — ตัวสร้าง ToolAcre ให้ CSPRNG ที่ได้รับการสนับสนุน UUID แก่คุณ เพื่อใช้เป็นคีย์เมื่อทดสอบการรวมระบบด้วยมือ
เครือข่ายหมดเวลาและไคลเอนต์ไม่เห็นการตอบสนองตั้งแต่ครั้งแรกที่พยายาม แอปลองคำขอเดียวกันอีกครั้งด้วยคีย์ idempotency เดียวกันโดยไม่สร้าง UUID ใหม่ เซิร์ฟเวอร์จดจำคีย์ในแคช ค้นหาการตอบสนองที่แคชไว้ และส่งคืน {status: "success", transferId: "xfer-12345"} ทันที โดยไม่ต้องประมวลผลการโอนใหม่และไม่ต้องเรียกเก็บเงินจากลูกค้าอีกครั้ง การดำเนินการเป็นแบบ idempotent การลองใหม่อีกครั้งจะให้ผลลัพธ์ที่สังเกตได้เหมือนเดิมทุกครั้ง สำหรับการทดสอบที่ใช้งานได้ ตัวสร้าง ToolAcre สามารถจัดเตรียมคีย์ได้ สร้าง UUID รวมไว้ในส่วนหัว สังเกตการตอบสนองและส่งอีกครั้งด้วยคีย์เดียวกันเพื่อตรวจสอบว่าเซิร์ฟเวอร์ใช้แคชอย่างถูกต้อง