การจัดการข้อผิดพลาดของ Tracking API: วิธีจัดการหมายเลขติดตามที่ไม่ถูกต้อง ขีดจำกัดอัตราการเรียกใช้งาน และการลองใหม่
จัดการข้อผิดพลาดของ API การติดตามโดยแยกอินพุตที่ไม่ถูกต้อง ความล้มเหลวชั่วคราว ขีดจำกัดอัตราการร้องขอ และผลลัพธ์สถานะการจัดส่ง ปฏิเสธหรือแก้ไขหมายเลขติดตามที่ไม่ถูกต้องแทนการลองส่งซ้ำโดยไม่เปลี่ยนแปลง ประสานปริมาณคำขอเมื่อถูกจำกัดอัตรา และลองส่งซ้ำสำหรับความล้มเหลวชั่วคราวด้วยการหน่วงเวลาแบบเอ็กซ์โพเนนเชียลที่มีขอบเขตและมี jitter ก่อนส่งคำขอลงทะเบียนหรือคำขอเขียนอื่นซ้ำ ให้ตรวจสอบก่อนว่าการพยายามครั้งแรกสำเร็จหรือไม่
สำหรับนักพัฒนาที่เชื่อมต่อข้อมูลการติดตามเข้ากับระบบจัดการคำสั่งซื้อ แพลตฟอร์มคลังสินค้า หรือหน้าการติดตามที่ลูกค้าใช้งาน เป้าหมายไม่ได้มีเพียงการลดคำขอที่ล้มเหลว แต่คือการแสดงสถานะการจัดส่งที่เชื่อถือได้ โดยไม่มีการลงทะเบียนซ้ำ การลองส่งซ้ำเป็นระลอก ข้อความการจัดส่งที่ทำให้เข้าใจผิด หรือคำขอความช่วยเหลือที่ไม่จำเป็น
จำแนกความล้มเหลวก่อนเลือกการตอบสนอง
การผสานรวมระบบติดตามมีผลลัพธ์หลายส่วนที่ต้องประเมินแยกกัน ได้แก่ คำขอเครือข่ายเสร็จสมบูรณ์หรือไม่ API ยอมรับการดำเนินการหรือไม่ รายการติดตามแต่ละรายการที่ร้องขอสำเร็จหรือไม่ และมีเหตุการณ์การจัดส่งให้ใช้งานหรือไม่ การปฏิบัติต่อทั้งสี่ส่วนเสมือนเป็นแฟล็กสำเร็จหรือล้มเหลวเพียงตัวเดียวจะทำให้เกิดข้อผิดพลาดที่หลีกเลี่ยงได้
การตอบกลับสำเร็จของ HTTP ไม่ได้หมายความว่าทุกรายการในชุดคำขอจะสำเร็จเสมอไป ในทางกลับกัน การค้นหาที่ประมวลผลสำเร็จแต่ไม่มีเหตุการณ์การติดตาม ก็ไม่ได้หมายความว่า API ล้มเหลวเสมอไป ตรวจสอบเนื้อหาการตอบกลับและใช้ความหมายที่ผู้ให้บริการระบุไว้สำหรับผลลัพธ์แต่ละรายการ
| เงื่อนไข | การดำเนินการที่แนะนำ | ลองส่งซ้ำโดยไม่เปลี่ยนแปลงหรือไม่? |
|---|---|---|
| หมายเลขมีรูปแบบผิดหรือฟิลด์คำขอไม่ถูกต้อง | ตรวจสอบและแก้ไขอินพุต | ไม่ |
| ข้อมูลรับรองหายไปหรือไม่ถูกต้อง | ตรวจสอบข้อมูลรับรอง สิทธิ์ และสภาพแวดล้อม | ยังไม่ควร จนกว่าจะแก้ไขแล้ว |
| การตอบกลับว่าถึงขีดจำกัดอัตรา | หน่วงงานที่ได้รับผลกระทบและลดแรงกดดันจากคำขอร่วม | หลังรอครบเวลาที่กำหนด หากปลอดภัย |
| บริการล้มเหลวชั่วคราว | ใช้การหน่วงเวลาแบบมีขอบเขตและตรวจสอบความปลอดภัยของการดำเนินการ | โดยทั่วไปทำได้ ภายในงบประมาณการลองซ้ำ |
| หมดเวลาหลังส่งการลงทะเบียน | ตรวจสอบว่าการลงทะเบียนมีอยู่หรือไม่ | ไม่ควรทำโดยไม่ตรวจสอบ |
| ยอมรับการค้นหาแล้วแต่ไม่มีเหตุการณ์การจัดส่ง | ดำเนินการตามวงจรชีวิตการติดตามที่ระบุไว้ในเอกสาร | ใช้การรีเฟรชตามกำหนดเวลา ไม่ใช่การลองซ้ำอย่างรวดเร็ว |
รหัสสถานะ HTTP เป็นจุดเริ่มต้น ไม่ใช่แผนผังการตัดสินใจที่ครบถ้วนสำหรับผู้ให้บริการแต่ละราย RFC 9110 กำหนดความหมายของ HTTP ขณะที่ RFC 6585 กำหนด 429 Too Many Requests การผสานรวมของคุณควรตีความรหัสข้อผิดพลาดระดับแอปพลิเคชันและผลลัพธ์ระดับรายการที่มีการระบุไว้ในเอกสารด้วย
หมายเลขติดตามที่ไม่ถูกต้อง: แยกอินพุตผิดออกจากการไม่มีเหตุการณ์
คำว่า “หมายเลขติดตามไม่ถูกต้อง” อาจหมายถึงปัญหาหลายอย่าง ได้แก่ ตัวระบุมีรูปแบบผิด การจับคู่ผู้ขนส่งกับหมายเลขไม่รองรับ ไม่มีฟิลด์ผู้ขนส่งที่จำเป็น หรือความล้มเหลวในการตรวจสอบอื่นที่ขึ้นอยู่กับผู้ให้บริการ อย่าสรุปว่าหมายเลขไม่ถูกต้องเพียงเพราะไม่มีเหตุการณ์การติดตามส่งกลับมา
ตรวจสอบโดยไม่ทำให้ตัวระบุเสียหาย
- จัดเก็บหมายเลขติดตามเป็นสตริง การจัดเก็บเป็นตัวเลขอาจลบเลขศูนย์นำหน้าหรือเปลี่ยนแปลงตัวระบุที่มีความยาวมาก
- เก็บอินพุตต้นฉบับไว้ เก็บค่าที่ทำให้เป็นมาตรฐานแยกต่างหาก เพื่อให้ตรวจสอบย้อนกลับการแปลงได้
- ทำให้เป็นมาตรฐานอย่างระมัดระวัง ลบช่องว่างโดยรอบเมื่อเหมาะสม แต่ลบอักขระภายในหรือเปลี่ยนตัวพิมพ์เฉพาะเมื่อกฎที่ระบุไว้ในเอกสารอนุญาต
- ตรวจสอบฟิลด์ที่จำเป็นในเครื่อง ตรวจจับหมายเลขว่าง ตัวระบุผู้ขนส่งที่หายไป และรูปแบบคำขอที่ไม่ถูกต้องก่อนส่ง
- หลีกเลี่ยง regex หมายเลขติดตามแบบสากล กฎที่ออกแบบสำหรับผู้ขนส่งรายหนึ่งอาจปฏิเสธตัวระบุที่ถูกต้องของอีกราย
- ยืนยันว่าในฟิลด์มีข้อมูลประเภทใด หมายเลขคำสั่งซื้อ ข้อมูลอ้างอิงคลังสินค้า และหมายเลขติดตามของผู้ขนส่งไม่สามารถใช้แทนกันได้ เว้นแต่ endpoint จะรองรับอย่างชัดเจน
หาก API ปฏิเสธอินพุตอย่างชัดเจน ให้ส่งต่อไปแก้ไขแทนการเข้าสู่วงจรการลองซ้ำอัตโนมัติ ควรระบุเหตุผลที่เป็นประโยชน์ เช่น “ต้องระบุตัวระบุผู้ขนส่ง” แทนการลดปัญหาการตรวจสอบทั้งหมดให้เหลือเพียง “การติดตามล้มเหลว”
ถือว่า “ไม่มีเหตุการณ์” เป็นสถานะแยกต่างหาก
การจัดส่งอาจมีตัวระบุการติดตามก่อนที่เหตุการณ์การเคลื่อนย้ายที่เป็นประโยชน์จะพร้อมใช้งาน การตอบสนองที่ถูกต้องขึ้นอยู่กับโมเดลสถานะที่ระบุไว้ในเอกสารของ API และบริบทของการจัดส่ง ตรวจสอบว่าตัวระบุมาจากระบบการจัดส่งหรือไม่ การเลือกผู้ขนส่งถูกต้องหรือไม่ และการตอบกลับระบุว่าข้อมูลอยู่ระหว่างรอหรือเป็นอินพุตที่ถูกปฏิเสธ
ใช้สถานะภายในที่แตกต่างกัน เช่น input_rejected, awaiting_events และ temporarily_unavailable สถานะเหล่านี้เป็นสถานะแอปพลิเคชันที่แนะนำ ไม่ใช่ค่ามาตรฐานของ API ช่วยป้องกันไม่ให้ช่องว่างของข้อมูลชั่วคราวกลายเป็นข้อความที่ไม่ถูกต้องสำหรับลูกค้า
จัดการขีดจำกัดอัตราทั่วทั้งระบบ ไม่ใช่แยกตาม worker
RFC 6585 กำหนด HTTP 429 ให้เป็นการตอบกลับเมื่อถูกจำกัดอัตรา และอนุญาตให้มีส่วนหัว Retry-After มาตรฐานไม่ได้กำหนดขีดจำกัดหรือวิธีนับแบบสากลสำหรับ API การติดตาม ขีดจำกัดอาจกำหนดตามบัญชี ข้อมูลรับรอง endpoint หรือขอบเขตอื่น ให้ใช้กฎจริงของผู้ให้บริการ
RFC 9110 ระบุรูปแบบของ Retry-After ไว้สองแบบ ได้แก่ จำนวนวินาทีที่ไม่ติดลบหรือวันที่แบบ HTTP ให้แยกวิเคราะห์ทั้งสองแบบ หากค่าเป็นวันที่ ให้คำนวณเวลารอที่เหลืออย่างรอบคอบและคำนึงถึงความแตกต่างของนาฬิกา หากไม่มีค่าหรือใช้งานไม่ได้ ให้ใช้นโยบายการหน่วงเวลาสำรองที่กำหนดค่าไว้
การให้ worker หนึ่งหยุดรอโดยอิสระไม่เพียงพอ หาก worker อื่นยังคงใช้โควตาเดียวกัน ควรวางการควบคุมอัตราไว้ที่ขอบเขตร่วมสำหรับข้อมูลรับรองหรือบัญชีที่เกี่ยวข้อง ตัวจัดตารางส่วนกลาง token bucket ร่วม หรือการควบคุมแบบกระจายที่เทียบเท่ากัน สามารถประสานปริมาณการรับส่งข้อมูลได้
- ระบุขอบเขตที่ได้รับผลกระทบ ตรวจสอบว่าขีดจำกัดใช้กับ endpoint ข้อมูลรับรอง หรือบัญชีใด
- ปฏิบัติตามคำสั่งเวลารอของเซิร์ฟเวอร์ อย่ากำหนดการลองซ้ำให้เร็วกว่าค่าที่ถูกต้องของ
Retry-After - หน่วงงานที่อยู่ในคิวและได้รับผลกระทบ หลีกเลี่ยงการบล็อกทราฟฟิกที่ไม่เกี่ยวข้องเมื่อขีดจำกัดแยกจากกันจริง
- ลดการทำงานพร้อมกันหรือความถี่ของคำขอ การรอเพียงครั้งเดียวโดยไม่เปลี่ยนรูปแบบคำขออาจทำให้เกิดปัญหาเดิมซ้ำ
- กลับมาทำงานโดยเว้นระยะ อย่าปล่อยงานค้างทั้งหมดพร้อมกันเมื่อหมดเวลารอ
หากรองรับ การส่งเป็นชุดสามารถลดจำนวนคำขอได้ แต่ต้องปฏิบัติตามกฎขนาดชุดและการนับที่ระบุไว้ในเอกสาร อย่าสรุปว่าชุดคำขอหนึ่งชุดใช้โควตาหนึ่งหน่วย ในทำนองเดียวกัน ให้ใช้ webhook เมื่อมี เพื่อ ลดการ polling ที่หลีกเลี่ยงได้ พร้อมคงกระบวนการกระทบยอดที่ระบบของคุณจำเป็นต้องใช้
ใช้การลองซ้ำแบบมีขอบเขตพร้อมการหน่วงเวลาและ jitter
การลองซ้ำเหมาะสมเมื่อความล้มเหลวอาจหายไปได้โดยไม่ต้องเปลี่ยนคำขอ และการดำเนินการซ้ำมีความปลอดภัย ความล้มเหลวของการเชื่อมต่อชั่วคราวและข้อผิดพลาดจากเซิร์ฟเวอร์บางประเภทอาจอยู่ในกลุ่มนี้ ส่วน payload ที่มีรูปแบบผิด ข้อมูลรับรองไม่ถูกต้อง หรือปัญหาสิทธิ์ถาวร โดยทั่วไปต้องแก้ไขแทน
วิธีสำรองที่ใช้ได้จริงคือการหน่วงเวลาแบบเอ็กซ์โพเนนเชียลที่มีเพดานและ full jitter:
backoff_window = min(max_delay, base_delay * 2^retry_index)
jitter_delay = random(0, backoff_window)
next_delay = max(valid_retry_after_delay, jitter_delay)ในที่นี้ retry_index เริ่มที่ศูนย์สำหรับการลองซ้ำครั้งแรก และ Retry-After ที่ไม่มีค่าจะไม่เพิ่มเวลารอขั้นต่ำใด ๆ นี่เป็นตัวเลือกในการใช้งาน ไม่ใช่อัลกอริทึม HTTP ที่บังคับใช้ ให้เลือกเวลาหน่วงพื้นฐาน เพดาน จำนวนครั้งที่อนุญาต และกำหนดเวลารวมให้เหมาะกับภาระงานและคำแนะนำของผู้ให้บริการ
Jitter ช่วยกระจายคำขอตามเวลา แทนที่จะให้ worker ทุกตัวลองซ้ำตามกำหนดเวลาเดียวกัน เพดานเวลาหน่วงจะจำกัดส่วนเอ็กซ์โพเนนเชียล แต่ไม่ควรแทนที่เวลารอที่ยาวกว่าซึ่งเซิร์ฟเวอร์ร้องขออย่างถูกต้อง หากเวลารอดังกล่าวเกินกำหนดเวลาของงาน ให้เลื่อนหรือยุติงานตามนโยบาย แทนการลองซ้ำก่อนเวลา
กำหนดจุดสิ้นสุดให้ทุกสายการลองซ้ำ
- ขีดจำกัดจำนวนครั้ง: จำกัดจำนวนคำขอเพิ่มเติม
- ขีดจำกัดเวลาที่ผ่านไป: หยุดลองซ้ำงานที่เกินช่วงเวลาการประมวลผลที่ยังมีประโยชน์
- ความรับผิดชอบที่ชัดเจน: เลือกเลเยอร์ที่ควบคุมการลองซ้ำ เพื่อไม่ให้การลองซ้ำของ HTTP client และคิวเพิ่มจำนวนทับซ้อนกันโดยไม่คาดคิด
- การจัดตารางที่คงทน: จัดเก็บงานที่เลื่อนเวลาไว้ แทนการพึ่งพาการหยุดรอนานภายในกระบวนการอายุสั้น
- เส้นทางการกู้คืน: ส่งงานที่ลองซ้ำจนหมดไปยังคิวงานล้มเหลวที่ตรวจสอบได้ พร้อมเหตุผลและการดำเนินการถัดไป
ในช่วงที่บริการหยุดชะงักเป็นเวลานาน ให้พิจารณา circuit breaker ที่หยุดการเรียกตามปกติชั่วคราวและอนุญาตให้ตรวจสอบการกู้คืนแบบควบคุมได้ นี่เป็นรูปแบบความทนทานของแอปพลิเคชัน ไม่ใช่หลักฐานว่าผู้ให้บริการติดตามรายใดรายหนึ่งจำเป็นต้องใช้
แก้ไขการเขียนที่คลุมเครือก่อนส่งซ้ำ
การหมดเวลาบอกเพียงว่าแอปพลิเคชันของคุณไม่ได้รับการตอบกลับที่สมบูรณ์ ไม่ได้พิสูจน์ว่าเซิร์ฟเวอร์ปฏิเสธหรือไม่เคยประมวลผลคำขอ ความแตกต่างนี้สำคัญเมื่อลงทะเบียนหมายเลขติดตามหรือเปลี่ยนแปลงการกำหนดค่าการติดตาม
RFC 9110 อธิบายเมธอดที่เป็น idempotent และเตือนไม่ให้ลองส่งคำขอที่ไม่เป็น idempotent ซ้ำโดยอัตโนมัติ หากไม่มีพื้นฐานที่จะทราบว่าการทำซ้ำปลอดภัยหรือการดำเนินการเดิมไม่ได้ถูกนำไปใช้ ให้ประเมินความหมายของการดำเนินการตามเอกสาร แทนการสรุปว่า endpoint การติดตามทุกตัวทำงานเหมือนการค้นหาแบบอ่านอย่างเดียว
- ใช้กลไก idempotency ที่ผู้ให้บริการระบุไว้เมื่อมี โดยปฏิบัติตามขอบเขตและกฎการเก็บรักษา
- ใช้ idempotency key เดิมสำหรับการลองซ้ำของการดำเนินการเชิงตรรกะเดียวกัน อย่าสรุปว่า header ที่กำหนดเองแบบใด ๆ จะได้รับการยอมรับ
- หากรองรับ ให้ตรวจสอบการลงทะเบียนที่มีอยู่ก่อนทำการเขียนที่คลุมเครือซ้ำ
- ใช้ข้อจำกัดความไม่ซ้ำกันในเครื่องให้สอดคล้องกับตัวตนของการจัดส่งที่ผู้ให้บริการระบุไว้
- จัดเก็บผลลัพธ์ของการดำเนินการ เพื่อไม่ให้การส่งงานในคิวซ้ำกระตุ้นการเขียนอีกครั้งโดยอัตโนมัติ
สำหรับการดำเนินการแบบชุด ให้บันทึกผลลัพธ์ของแต่ละรายการ ลองส่งซ้ำเฉพาะรายการที่จำแนกว่าเป็นความล้มเหลวชั่วคราว และกระทบยอดรายการที่ยังไม่ทราบผลลัพธ์ การส่งทั้งชุดซ้ำอาจทำให้งานที่สำเร็จแล้วเกิดซ้ำและใช้โควตาคำขอโดยไม่จำเป็น
ปรับใช้นโยบายกับผู้ให้บริการติดตามของคุณ
สำหรับการผสานรวม 17TRACK ให้ใช้ หน้า Tracking API และ เอกสาร API อย่างเป็นทางการ เป็นจุดเริ่มต้นสำหรับสัญญาเฉพาะของผู้ให้บริการ ควรทำให้ตัวจำแนกข้อผิดพลาดสามารถกำหนดค่าได้ แทนการฝังสมมติฐานจากคู่มือ HTTP ทั่วไป
ก่อนการใช้งาน ให้ยืนยัน schema ของคำขอของ endpoint ที่เกี่ยวข้อง ซองการตอบกลับ ความหมายของข้อผิดพลาดระดับรายการ ขอบเขตการจำกัดอัตรา ข้อจำกัดของชุดคำขอ และกฎสำหรับการส่งซ้ำ นอกจากนี้ หากใช้การส่งเหตุการณ์ ให้ตรวจสอบข้อกำหนดด้านการตอบรับ การยืนยันตัวตน และการส่งซ้ำด้วย คู่มือนี้ไม่ได้กำหนดขีดจำกัดอัตรา ตารางการลองซ้ำ หรือฟีเจอร์ idempotency ของ 17TRACK ในรูปแบบตัวเลข
บันทึกกฎที่ยืนยันแล้วแต่ละข้อในรูปแบบการจับคู่ระหว่างการตอบกลับของผู้ให้บริการกับการดำเนินการของแอปพลิเคชัน ได้แก่ แก้ไขอินพุต ซ่อมแซมการกำหนดค่า รอ กระทบยอด หรือยกระดับปัญหา ข้อผิดพลาดที่ไม่รู้จักควรเก็บบริบทสำหรับการวินิจฉัยและเข้าสู่เส้นทางสำรองที่มีขอบเขต ไม่ใช่เข้าสู่การลองซ้ำแบบไม่จำกัดโดยอัตโนมัติ
ติดตามคุณภาพการกู้คืนและทดสอบเส้นทางความล้มเหลว
บันทึกการดำเนินการ endpoint สถานะ HTTP รหัสข้อผิดพลาดของแอปพลิเคชัน หมายเลขครั้งที่ลองซ้ำ เวลาแฝง การดำเนินการถัดไปที่กำหนดเวลาไว้ และตัวระบุคำขอของผู้ให้บริการเมื่อมีให้ หลีกเลี่ยงการบันทึก API key ข้อมูลที่อยู่ที่ไม่จำเป็น หรือเนื้อหาการตอบกลับแบบไม่จำกัด ควรปกปิดหรือแฮชตัวระบุการติดตามเมื่อไม่จำเป็นต้องใช้ค่าทั้งหมด
ติดตามอัตราอินพุตไม่ถูกต้อง การจำกัดอัตรา อายุของคิว การลองซ้ำจนหมด และการซิงโครไนซ์ที่สำเร็จครั้งล่าสุดแยกจากกัน ระบบผสานรวมอาจมีอัตราข้อผิดพลาด HTTP ต่ำ แต่ยังคงแสดงข้อมูลการจัดส่งที่ล้าสมัย หน้าที่ลูกค้าเห็นควรรักษาสถานะการจัดส่งล่าสุดที่ทราบ และแยกความล้มเหลวในการรีเฟรชออกจากเหตุการณ์การจัดส่งที่ผู้ขนส่งรายงาน
ก่อนเผยแพร่ ให้ทดสอบอินพุตที่มีรูปแบบผิด ตัวระบุที่ถูกต้องแต่ไม่มีเหตุการณ์ รูปแบบทั้งสองของ Retry-After header ที่หายไป ความล้มเหลวบางส่วนของชุดคำขอ การหมดเวลาหลังการเขียน และการส่งงานในคิวซ้ำ นอกจากนี้ให้จำลองการหยุดชะงักที่ยาวนานพอจนใช้งบประมาณการลองซ้ำหมด การทดสอบจะผ่านก็ต่อเมื่องานหยุดหรือถูกเลื่อนอย่างคาดการณ์ได้ รายการที่สำเร็จไม่ถูกส่งซ้ำโดยไม่จำเป็น และรายการที่ล้มเหลวยังคงกู้คืนได้
คำถามที่พบบ่อย
ควรลองส่งหมายเลขติดตามที่ไม่ถูกต้องซ้ำโดยอัตโนมัติหรือไม่?
ไม่ควร หาก API ปฏิเสธอินพุตอย่างชัดเจนว่าไม่ถูกต้อง ให้แก้ไขหมายเลข การเลือกผู้ขนส่ง หรือฟิลด์ที่จำเป็นก่อน หากการตอบกลับหมายความเพียงว่ายังไม่มีเหตุการณ์การจัดส่ง ให้ใช้ขั้นตอนการรีเฟรชตามเอกสาร แทนการถือว่าเป็นความล้มเหลวในการตรวจสอบ
HTTP 200 หมายความว่าคำขอแบบชุดสำเร็จทั้งหมดหรือไม่?
ไม่จำเป็นต้องเป็นเช่นนั้น ตรวจสอบ schema การตอบกลับของผู้ให้บริการสำหรับผลลัพธ์ระดับการดำเนินการและระดับรายการ บันทึกความสำเร็จและแยกความล้มเหลว เพื่อให้การลองซ้ำรายการหนึ่งไม่ทำให้รายการที่เหลือถูกทำซ้ำโดยไม่จำเป็น
การผสานรวมระบบติดตามควรอนุญาตให้ลองซ้ำกี่ครั้ง?
ไม่มีจำนวนสากล กำหนดทั้งขีดจำกัดจำนวนครั้งและงบประมาณเวลาที่ผ่านไป โดยพิจารณาจากคำแนะนำของผู้ให้บริการ ความปลอดภัยของการดำเนินการ และระยะเวลาที่ผลลัพธ์ยังมีประโยชน์ การซิงโครไนซ์เบื้องหลังตามกำหนดเวลาอาจรองรับช่วงเวลาการกู้คืนที่แตกต่างจากคำขอของลูกค้าแบบโต้ตอบ
ควรระบุว่าการจัดส่งล้มเหลวทันทีเมื่อหมดเวลาหรือไม่?
ไม่ การหมดเวลาของคำขอเป็นผลลัพธ์ของการผสานรวม ไม่ใช่เหตุการณ์การจัดส่ง รักษาสถานะการติดตามล่าสุดที่ทราบ กำหนดการกู้คืนที่ปลอดภัย และหลีกเลี่ยงการเปลี่ยนปัญหาการเชื่อมต่อให้กลายเป็นการแจ้งเตือนการจัดส่งล้มเหลว
ควรทำอย่างไรเมื่อการลองซ้ำหมดลง?
ย้ายงานไปยังคิวงานล้มเหลวหรือคิวตรวจสอบที่คงทน พร้อมบริบทสำหรับการวินิจฉัย ระบุว่าการกู้คืนจำเป็นต้องแก้ไขอินพุต กู้คืนข้อมูลรับรอง ขอความช่วยเหลือจากผู้ให้บริการ หรือเล่นงานซ้ำแบบควบคุมในภายหลัง อย่าทิ้งงานอย่างเงียบ ๆ หรือเริ่มวงจรการลองซ้ำแบบไม่จำกัดเดิมอีกครั้ง
แหล่งข้อมูล
- RFC 9110: HTTP Semantics — ความหมายของสถานะ HTTP เมธอดที่เป็น idempotent ข้อควรพิจารณาเกี่ยวกับการลองซ้ำอัตโนมัติ และฟิลด์ Retry-After
- RFC 6585: Additional HTTP Status Codes — คำจำกัดความของ 429 Too Many Requests และส่วนหัว Retry-After ที่เป็นตัวเลือก
- 17TRACK Tracking API — จุดเริ่มต้นอย่างเป็นทางการสำหรับผลิตภัณฑ์ API การติดตาม
- 17TRACK API documentation — เอกสารอ้างอิงสำหรับตรวจสอบข้อกำหนดการผสานรวมเฉพาะของผู้ให้บริการ
