สถานะการจัดส่งของ Shipping API: รหัสสถานะ, Webhooks และการแจ้งเตือนข้อยกเว้น
สถานะการจัดส่งของ shipping API อธิบายความคืบหน้าของพัสดุ ไม่ได้ระบุว่าคำขอ API สำเร็จหรือไม่ หากต้องการสร้างระบบติดตามที่เชื่อถือได้ ควรแยกรหัสการตอบกลับ HTTP ออกจากสถานะการจัดส่ง ประมวลผล webhook โดยไม่สันนิษฐานว่าจะมาถึงเพียงครั้งเดียวหรือตามลำดับ และเปลี่ยนข้อยกเว้นที่ต้องดำเนินการให้เป็นการแจ้งเตือนพร้อมผู้รับผิดชอบที่ชัดเจน สำหรับทีมวิศวกรรมและทีมปฏิบัติการอีคอมเมิร์ซ เป้าหมายคือบันทึกการจัดส่งที่ยังคงเชื่อถือได้เมื่อการอัปเดตจากผู้ให้บริการขนส่งล่าช้า ซ้ำกัน หรือถูกแก้ไข
คู่มือนี้อธิบายวิธีจัดโครงสร้างบันทึกดังกล่าว วิธีจัดการเหตุการณ์การติดตามที่เข้ามา และวิธีแยกแยะปัญหาการจัดส่งออกจากปัญหาการเชื่อมต่อระบบติดตาม
แยกรหัส HTTP ผลลัพธ์ API และสถานะการจัดส่งออกจากกัน
คำว่า “รหัสสถานะ” อาจหมายถึงสามชั้นที่แตกต่างกัน การนำมาปะปนกันจะทำให้แดชบอร์ดทำให้เข้าใจผิดและส่งการแจ้งเตือนลูกค้าโดยไม่จำเป็น
| ชั้น | ข้อมูลที่บอกคุณ | ตัวอย่างการตีความ |
|---|---|---|
| การตอบกลับ HTTP | ผลลัพธ์ของคำขอ HTTP | การตอบกลับ 200 แสดงว่าคำขอสำเร็จในระดับ HTTP แต่ไม่ได้หมายความว่าพัสดุถูกจัดส่งแล้ว |
| ผลลัพธ์ทางธุรกิจของ API | การดำเนินการที่ร้องขอสำเร็จภายใต้กฎของแอปพลิเคชันของผู้ให้บริการหรือไม่ | เนื้อหาการตอบกลับอาจรายงานว่าการลงทะเบียนการติดตามถูกปฏิเสธ แม้อยู่ภายในการตอบกลับ HTTP ที่สำเร็จ หาก API ใช้รูปแบบดังกล่าว |
| สถานะการจัดส่ง | สภาพทางกายภาพหรือการดำเนินงานของพัสดุที่มีการรายงาน | อยู่ระหว่างการขนส่ง รอรับพัสดุ หรือจัดส่งแล้ว |
มาตรฐานความหมายของ HTTP กำหนดความหมายของการตอบกลับ HTTP ตัวอย่างเช่น 202 Accepted หมายความว่าคำขอได้รับการยอมรับเพื่อประมวลผล แต่การประมวลผลอาจยังไม่เสร็จสิ้น ไม่ใช่หลักฐานว่าผู้ให้บริการขนส่งรับพัสดุแล้ว
เช่นเดียวกัน คำขอติดตามที่ล้มเหลวไม่ได้พิสูจน์ว่าการจัดส่งหยุดเคลื่อนที่ แอปพลิเคชันของคุณอาจสูญเสียการมองเห็นชั่วคราวขณะที่การจัดส่งจริงยังดำเนินต่อไปตามปกติ ควรตรวจสอบแต่ละชั้นแยกจากกัน
สร้างโมเดลสถานะโดยไม่ละทิ้งรายละเอียดจากผู้ให้บริการขนส่ง
ไม่มีรหัสสถานะการจัดส่งแบบตัวเลขสากลที่ใช้ร่วมกันโดย shipping API และผู้ให้บริการขนส่งทุกราย ไม่ควรตีความค่าจากการเชื่อมต่อระบบหนึ่งโดยใช้การแมปของผู้ให้บริการอีกราย ให้ใช้เอกสารของ API เวอร์ชันเฉพาะที่คุณนำไปใช้งาน
โมเดลภายในที่ใช้งานได้จริงควรรวมสถานะมาตรฐานจำนวนเล็กน้อยเข้ากับเหตุการณ์เดิมจากผู้ให้บริการขนส่ง การทำให้เป็นมาตรฐานช่วยให้รายงานมีความสอดคล้อง ส่วนเหตุการณ์เดิมจะเก็บรายละเอียดที่จำเป็นต่อการตรวจสอบ
| สถานะภายในตัวอย่าง | ความหมาย | ข้อควรระวังด้านการดำเนินงาน |
|---|---|---|
| ได้รับข้อมูลแล้ว | มีข้อมูลการจัดส่งทางอิเล็กทรอนิกส์อยู่ | อย่าถือว่าการสร้างฉลากเป็นการยืนยันการส่งมอบพัสดุจริง |
| อยู่ระหว่างการขนส่ง | บันทึกการติดตามระบุว่าพัสดุกำลังเคลื่อนผ่านเครือข่ายการจัดส่ง | หมวดหมู่กว้างนี้อาจครอบคลุมขั้นตอนการขนส่งที่แตกต่างกัน |
| กำลังนำจ่าย | มีรายงานว่าพัสดุอยู่บนเส้นทางนำจ่าย | อย่าเปลี่ยนสถานะนี้ให้เป็นคำรับประกันการจัดส่งแบบไม่มีเงื่อนไข |
| รอรับพัสดุ | คาดว่าผู้รับจะมารับพัสดุ | ใส่คำแนะนำหรือกำหนดเวลารับพัสดุเฉพาะเมื่อแหล่งข้อมูลรองรับเท่านั้น |
| จัดส่งแล้ว | แหล่งข้อมูลการติดตามรายงานว่าจัดส่งแล้ว | การสแกนการจัดส่งเพียงอย่างเดียวไม่สามารถยุติข้อเรียกร้องของลูกค้าที่ระบุว่าไม่ได้รับพัสดุ |
| ข้อยกเว้น | เหตุการณ์อาจต้องได้รับการดูแลหรือขัดจังหวะความคืบหน้าตามปกติ | เก็บเหตุผลไว้แทนการถือว่าข้อยกเว้นทุกกรณีคือพัสดุสูญหาย |
| กำลังส่งคืนหรือส่งคืนแล้ว | พัสดุกำลังเคลื่อนกลับหรือมีรายงานว่าส่งคืนเสร็จแล้ว | แยกความคืบหน้าการส่งคืนออกจากการจัดส่งไปยังผู้รับเดิม |
| ไม่ทราบ | ไม่สามารถแมปข้อมูลที่มีอยู่ได้อย่างมั่นใจ | ตรวจสอบการแมปหรือช่องว่างของข้อมูล แทนการสร้างสถานะการจัดส่งขึ้นเอง |
ป้ายกำกับเหล่านี้เป็นโมเดลแอปพลิเคชันที่เสนอ ไม่ใช่รายการรหัสอย่างเป็นทางการของ 17TRACK ควรเก็บรหัสสถานะของผู้ให้บริการ รหัสสถานะย่อย คำอธิบาย เวลาของเหตุการณ์ ข้อมูลเขตเวลา สถานที่ และเวลาที่ได้รับไว้เมื่อมีข้อมูล นอกจากนี้ควรเก็บเวอร์ชันของการแมปไว้ เพื่อให้สามารถตรวจสอบการเปลี่ยนแปลงการแมปในภายหลังได้
สำหรับการใช้งานกับผู้ให้บริการขนส่งหลายราย 17TRACK Tracking API เป็นตัวเลือกการเชื่อมต่อที่เกี่ยวข้อง ใช้ เอกสาร API อย่างเป็นทางการ เพื่อกำหนดข้อตกลงการใช้งาน แทนการคัดลอกป้ายกำกับตัวอย่างไปใส่ในฟิลด์เฉพาะของผู้ให้บริการ ก่อนสร้างอะแดปเตอร์ ให้ยืนยันคำจำกัดความสถานะที่เกี่ยวข้อง การกำหนดค่า webhook ข้อกำหนดการยืนยันตัวตน และความหมายของการตอบกลับ
สร้างการจัดการ webhook โดยยึดการรับข้อมูลที่คงทน
Webhook คือคำขอ HTTP ที่ส่งไปยัง endpoint ของคุณเพื่อรายงานเหตุการณ์ ซึ่งช่วยลดความจำเป็นในการเรียกตรวจสอบซ้ำ แต่ไม่ควรถือเป็นการรับประกันว่าจะส่งถึงทันที ตามลำดับ หรือเพียงครั้งเดียวพอดี ออกแบบตัวรับข้อมูลให้รองรับการลองส่งซ้ำ การหยุดชะงัก และ payload ที่ไม่คาดคิด เว้นแต่ผู้ให้บริการจะรับประกันไว้เป็นอย่างอื่นอย่างชัดเจน
- ยืนยันตัวตนของคำขอ ใช้วิธีตรวจสอบที่ผู้ให้บริการระบุไว้ในเอกสาร หากรองรับลายเซ็น ให้ตรวจสอบโดยใช้อัลกอริทึมและไบต์ดิบของคำขอตามที่กำหนด อย่าสร้างสมมติฐานเกี่ยวกับส่วนหัวลายเซ็นเอง หรือคิดว่าทุกบริการใช้ HMAC
- ตรวจสอบ payload ตรวจสอบฟิลด์ที่จำเป็น ชนิดข้อมูล ขนาด payload และความเชื่อมโยงกับการจัดส่งที่บัญชีของคุณจัดการ จัดการฟิลด์เสริมที่ไม่รู้จักโดยไม่ทำลายความเข้ากันได้ในอนาคตโดยไม่จำเป็น
- บันทึกข้อมูลก่อนตอบรับ จัดเก็บเหตุการณ์ที่ยอมรับแล้วหรือใส่ไว้ในคิวที่คงทนก่อนส่งการตอบกลับสำเร็จตามที่กำหนด หากการบันทึกล้มเหลว อย่าตอบรับเหตุการณ์ว่าได้รับอย่างปลอดภัย
- ประมวลผลแบบอะซิงโครนัส ดำเนินการแมปสถานะ อัปเดตคำสั่งซื้อ และตัดสินใจเรื่องการแจ้งเตือนนอกตัวจัดการคำขอเมื่อเหมาะสม
- ทำให้ผลข้างเคียงมี idempotency เหตุการณ์ที่ซ้ำกันไม่ควรสร้างตั๋วสนับสนุนเพิ่มหรือส่งข้อความเดียวกันให้ลูกค้าซ้ำอีกครั้ง
รหัสตอบรับที่แน่นอน ระยะหมดเวลา ตารางการลองส่งซ้ำ และพฤติกรรมการเล่นซ้ำขึ้นอยู่กับผู้ให้บริการ ให้ตรวจสอบรายละเอียดเหล่านี้โดยเฉพาะ คำแนะนำทั่วไปว่า “ให้ส่ง 200 กลับไป” ไม่สามารถใช้แทนข้อตกลง webhook ได้
ใช้ HTTPS และอย่าเก็บข้อมูลรับรองไว้ใน URL หรือ log ตามปกติ ใช้การควบคุมการเข้าถึงกับ payload ที่จัดเก็บ เนื่องจากข้อมูลการติดตามอาจมีข้อมูลส่วนบุคคล OWASP REST Security Cheat Sheet ให้คำแนะนำที่เกี่ยวข้องเกี่ยวกับการป้องกันการส่งข้อมูล การตรวจสอบอินพุต และความปลอดภัยของ endpoint
ลบเหตุการณ์ซ้ำโดยไม่ระงับการอัปเดตจริง
ควรใช้ตัวระบุเหตุการณ์ที่มีเอกสารรองรับและคงที่เมื่อมีให้ใช้ หากไม่มี ให้สร้างคีย์สำหรับลบข้อมูลซ้ำจากการผสมผสานอย่างระมัดระวังระหว่างตัวตนของการจัดส่ง เวลาของเหตุการณ์ รหัสเหตุการณ์ และสถานที่ ทดสอบแนวทางนี้กับ payload จริง เพราะเหตุการณ์ที่ถูกต้องสองเหตุการณ์อาจมีเวลาเดียวกัน และเหตุการณ์เดียวกันอาจมาพร้อมข้อความอธิบายที่แตกต่างกันเล็กน้อย
ใช้การควบคุมการลบข้อมูลซ้ำแยกกันสำหรับการรับเหตุการณ์และการดำเนินการปลายทาง การอัปเดตสถานะอาจต้องบันทึกซ้ำเพื่อแก้ไข ขณะที่การแจ้งเตือนลูกค้าควรยังคงถูกระงับ ให้การแจ้งเตือนหรือตั๋วแต่ละรายการมีตัวระบุถาวรของตนเอง
แยกเวลาเหตุการณ์ออกจากเวลาที่ได้รับ
สมมติว่าเหตุการณ์ที่อยู่ระหว่างการขนส่งมาถึงระบบของคุณหลังเหตุการณ์กำลังนำจ่าย แต่เวลาจากผู้ให้บริการขนส่งของเหตุการณ์แรกกลับเก่ากว่า ให้เก็บเหตุการณ์นั้นไว้ในประวัติโดยไม่เปลี่ยนสถานะปัจจุบันกลับเป็นอยู่ระหว่างการขนส่งโดยอัตโนมัติ
การเรียงลำดับตามเวลาเพียงอย่างเดียวไม่เพียงพอสำหรับทุกกรณี เขตเวลาที่หายไป การสแกนที่ถูกแก้ไข และแหล่งข้อมูลที่ขัดแย้งกันต้องใช้กฎที่ชัดเจน เก็บความละเอียดและค่า offset ของเวลาไว้ บันทึกเวลาที่ระบบของคุณได้รับแต่ละเหตุการณ์ และใช้ข้อมูลลำดับจากผู้ให้บริการที่มีเอกสารรองรับ อย่าบังคับใช้ลำดับสถานะที่เดินหน้าได้เท่านั้น เพราะความพยายามจัดส่ง การเปลี่ยนเส้นทาง การส่งคืน และการแก้ไขอาจสร้างการเปลี่ยนสถานะที่ถูกต้องแต่ดูเหมือนย้อนกลับ
เปลี่ยนข้อยกเว้นให้เป็นการดำเนินการที่มีผู้รับผิดชอบ
การแจ้งเตือนข้อยกเว้นควรอธิบายว่าเกิดอะไรขึ้น ต้องดำเนินการอะไร และใครเป็นผู้รับผิดชอบขั้นตอนถัดไป ข้อความทั่วไปอย่าง “ข้อยกเว้นในการจัดส่ง” ทำให้เจ้าหน้าที่ปฏิบัติการต้องตรวจสอบเรื่องเดิมซ้ำ และอาจทำให้ลูกค้ากังวลโดยไม่ได้ช่วยแก้ปัญหา
เริ่มจากนโยบายการจัดเส้นทางขนาดเล็ก:
- ปัญหาที่อยู่หรือการเข้าถึง: ส่งต่อให้ฝ่ายสนับสนุนลูกค้าตรวจสอบปัญหาและกระบวนการแก้ไขที่ผู้ให้บริการขนส่งมีให้ อย่าสัญญาว่าจะเปลี่ยนที่อยู่ก่อนยืนยันว่าทำได้
- ต้องไปรับพัสดุ: แจ้งผู้รับเมื่อแหล่งข้อมูลมีคำแนะนำการรับพัสดุที่ใช้งานได้ เก็บกำหนดเวลาที่ตรวจสอบแล้วไว้
- ต้องดำเนินการด้านศุลกากร: มอบหมายกรณีตามผู้ที่ต้องจัดเตรียมเอกสารหรือข้อมูลที่ร้องขอ เหตุการณ์ที่เกี่ยวข้องกับศุลกากรเพียงอย่างเดียวไม่ได้ยืนยันว่าต้องชำระเงิน
- พยายามจัดส่งไม่สำเร็จ: ตรวจสอบขั้นตอนถัดไปที่รายงานไว้ก่อนแนะนำให้จัดส่งใหม่หรือไปรับพัสดุ
- ส่งคืนผู้ส่ง: เปิดการตรวจสอบโดยฝ่ายปฏิบัติการ อย่าออกเงินคืนโดยอัตโนมัติเพียงจากป้ายกำกับการติดตามแบบกว้าง เว้นแต่นโยบายของคุณอนุญาตไว้อย่างชัดเจน
- ผู้ให้บริการรายงานว่าสูญหายหรือเสียหาย: ส่งต่อให้ผู้รับผิดชอบการเคลมและเก็บหลักฐานเหตุการณ์ไว้ แยกการตัดสินใจเรื่องเคลมออกจากการตรวจจับความล่าช้าทั่วไป
การแจ้งเตือนแต่ละรายการควรมีตัวระบุการจัดส่ง ข้อมูลอ้างอิงคำสั่งซื้อ เหตุผลของเหตุการณ์ เวลาจากแหล่งข้อมูล สถานะล่าสุดที่ทราบ ผู้รับผิดชอบ และการดำเนินการถัดไป ใส่ลิงก์ไปยังบันทึกภายในที่เกี่ยวข้องแทนการเปิดเผยรายละเอียดลูกค้าที่ไม่จำเป็นในช่องทางการสื่อสารร่วม
ถือว่า “ไม่มีการอัปเดต” เป็นเงื่อนไขแยกต่างหาก
การจัดส่งที่ไม่มีการสแกนล่าสุดไม่ได้หมายความว่าสูญหายโดยอัตโนมัติ อาจอยู่ระหว่างจุดตรวจ รอการสแกนทางกายภาพครั้งแรก หรือได้รับผลกระทบจากช่องว่างในการมองเห็น
กำหนดเกณฑ์การไม่มีความเคลื่อนไหวตามบริการ เส้นทาง ขั้นตอนการจัดส่ง และคำมั่นทางธุรกิจ แทนการใช้ตัวจับเวลาเดียวกับทุกกรณี แยกพัสดุที่ไม่เคยได้รับการสแกนรับพัสดุออกจากพัสดุที่หยุดอัปเดตหลังเข้าสู่เครือข่าย หากหลักฐานในอดีตมีจำกัด ให้ใช้เกณฑ์ดังกล่าวเพื่อเริ่มการตรวจสอบ ไม่ใช่ประกาศว่าพัสดุสูญหาย
ระงับการแจ้งเตือนซ้ำขณะที่กรณีที่ไม่มีการเปลี่ยนแปลงยังเปิดอยู่ ยกระดับเมื่อมีหลักฐานใหม่ พลาดการติดตามผลที่ตกลงไว้ หรือคำมั่นในการจัดส่งให้ลูกค้าจำเป็นต้องมีการแทรกแซง
ตรวจสอบสุขภาพการเชื่อมต่อแยกจากประสิทธิภาพการจัดส่ง
การตรวจสอบ API ตอบว่าการเชื่อมต่อระบบติดตามทำงานหรือไม่ การตรวจสอบการจัดส่งตอบว่าเกิดอะไรขึ้นกับพัสดุ endpoint ที่ทำงานปกติอาจได้รับข้อมูลเก่าจากผู้ให้บริการขนส่ง ขณะที่ endpoint ที่ไม่พร้อมใช้งานอาจพลาดการอัปเดตของพัสดุที่ยังเคลื่อนที่ตามปกติ
- สุขภาพของคำขอ: ติดตามความล้มเหลวในการยืนยันตัวตน การหมดเวลา การตอบกลับจำกัดอัตรา ข้อผิดพลาดของเซิร์ฟเวอร์ และการปฏิเสธระดับแอปพลิเคชัน
- สุขภาพของ webhook: ติดตามความล้มเหลวในการตรวจสอบ ความล่าช้าของการตอบรับ ความล้มเหลวในการบันทึก การส่งซ้ำ และข้อผิดพลาดในการประมวลผล
- สุขภาพของการประมวลผล: ตรวจสอบอายุคิว เหตุการณ์ที่ยังไม่ได้ประมวลผล ความล้มเหลวในการแมป และความล้มเหลวในการแจ้งเตือน
- ความใหม่ของข้อมูลติดตาม: วัดเวลานับจากเหตุการณ์ล่าสุดของแหล่งข้อมูลแยกจากเวลานับจากการรับข้อมูลสำเร็จครั้งล่าสุดของคุณ
- ผลลัพธ์ด้านการปฏิบัติการ: ติดตามข้อยกเว้นที่ยังไม่ได้แก้ไข เวลาจนถึงการมอบหมายผู้รับผิดชอบ และการติดตามผลที่เลยกำหนด
สำหรับการลองส่งคำขอซ้ำ ให้ปฏิบัติตามคำแนะนำของผู้ให้บริการเกี่ยวกับการจำกัดอัตราและการลองใหม่ หลีกเลี่ยงการทำซ้ำการดำเนินการที่อาจสร้างการลงทะเบียนซ้ำหรือผลข้างเคียงอื่น ๆ โดยไม่ตรวจสอบ ใช้กลไก idempotency ที่มีเอกสารรองรับเมื่อมีให้ใช้
เมื่อรองรับ ให้ใช้กระบวนการกระทบยอดเพื่อดึงบันทึกการติดตามล่าสุดหลังเกิดเหตุขัดข้องหรือสงสัยว่าพลาดเหตุการณ์ กำหนดความถี่ให้อยู่ภายในข้อจำกัดตามสัญญาและข้อจำกัดอัตรา Webhook และการกระทบยอดมีหน้าที่ต่างกัน โดย webhook ส่งการเปลี่ยนแปลง ส่วนการกระทบยอดช่วยตรวจจับและซ่อมแซมช่องว่าง
ทดสอบกรณีล้มเหลวก่อนเปิดใช้การแจ้งเตือนลูกค้า
เริ่มจากการประมวลผลภายในเท่านั้น และตรวจสอบพัสดุตัวอย่างก่อนอนุญาตให้การเปลี่ยนสถานะส่งข้อความถึงลูกค้า ทดสอบให้มากกว่าความคืบหน้าปกติจากอยู่ระหว่างการขนส่งไปสู่จัดส่งแล้ว
- Webhook ที่ซ้ำกันสร้างการแจ้งเตือนลูกค้าตามที่ตั้งใจเพียงหนึ่งรายการ
- เหตุการณ์เก่าที่มาถึงล่าช้าไม่แทนที่สถานะปัจจุบันอย่างไม่ถูกต้อง
- สถานะที่ไม่รู้จักยังคงถูกเก็บและทำเครื่องหมายไว้ แทนที่จะถูกแมปเป็นจัดส่งแล้วโดยเงียบ ๆ
- การบันทึกข้อมูลแบบคงทนที่ล้มเหลวไม่ก่อให้เกิดการตอบรับสำเร็จ
- การหยุดทำงานชั่วคราวของระบบปลายทางทำให้เหตุการณ์ยังพร้อมสำหรับการลองใหม่
- เหตุการณ์จัดส่งแล้วที่ตามด้วยการแก้ไขยังสามารถตรวจสอบย้อนหลังได้
- คำสั่งซื้อหลายพัสดุไม่ถูกเปลี่ยนเป็นจัดส่งครบทั้งหมดเมื่อมีเพียงพัสดุเดียวที่จัดส่งแล้ว
- การหยุดทำงานของ API แจ้งเตือนทีมวิศวกรรมโดยไม่บอกลูกค้าโดยอัตโนมัติว่าพัสดุล่าช้า
เกณฑ์การเผยแพร่ควรเป็นความสอดคล้องในการปฏิบัติงาน กล่าวคือ บันทึกการจัดส่ง ข้อความถึงลูกค้า และการดำเนินการของฝ่ายสนับสนุนต้องสอดคล้องกับหลักฐานพื้นฐานเดียวกัน การตอบกลับ webhook สำเร็จเพียงอย่างเดียวไม่ได้แสดงว่าประสบการณ์การจัดส่งทำงานได้
คำถามที่พบบ่อย
HTTP 200 หมายความว่าพัสดุถูกจัดส่งแล้วหรือไม่
ไม่ หมายถึงคำขอสำเร็จในระดับ HTTP เท่านั้น ให้อ่านผลลัพธ์ทางธุรกิจของ API และฟิลด์สถานะการจัดส่งแยกจากกัน สำหรับ webhook การตอบรับสำเร็จเกี่ยวข้องกับการรับการแจ้งเตือน ไม่ใช่การจัดส่งพัสดุจริง
ควรใช้ webhook หรือ polling สำหรับการอัปเดตการติดตาม
ใช้ webhook สำหรับการอัปเดตที่ขับเคลื่อนด้วยเหตุการณ์เมื่อผู้ให้บริการรองรับ หากรองรับและมีเหตุผลด้านการปฏิบัติงาน ให้เพิ่มการ polling เพื่อกระทบยอดในขอบเขตที่กำหนดเพื่อกู้คืนช่องว่าง การ polling เพียงอย่างเดียวอาจเหมาะสมเมื่อไม่มี webhook แต่ความถี่ต้องเคารพข้อจำกัดของผู้ให้บริการและข้อกำหนดด้านความใหม่ของข้อมูล
เหตุใดสถานะการติดตามจึงเปลี่ยนหลังจาก “จัดส่งแล้ว”
แหล่งข้อมูลอาจแก้ไขเหตุการณ์ หรือการเชื่อมต่อของคุณอาจได้รับข้อมูลที่ล่าช้าหรือขัดแย้งกัน เก็บประวัติไว้และประเมินหลักฐานใหม่ แทนการถือว่าสถานะจัดส่งแล้วไม่สามารถเปลี่ยนแปลงในทางเทคนิค การจัดส่งที่มีรายงานกับการยืนยันการรับของลูกค้าก็เป็นข้อเท็จจริงคนละเรื่องกัน
ควรส่งการแจ้งเตือนข้อยกเว้นเร็วเพียงใด
กำหนดความเร่งด่วนจากการดำเนินการที่จำเป็นและกำหนดเวลาที่ตรวจสอบแล้ว ปัญหาที่ต้องให้ผู้รับดำเนินการควรได้รับการจัดการแตกต่างจากความล่าช้าที่มีไว้เพื่อแจ้งข้อมูล ความเร็วในการประมวลผลไม่สามารถชดเชยเหตุการณ์จากผู้ให้บริการที่เผยแพร่ล่าช้าได้ ดังนั้นควรเก็บทั้งเวลาจากแหล่งข้อมูลและเวลาที่ได้รับ
ลูกค้าควรเห็นสถานะดิบจากผู้ให้บริการขนส่งหรือไม่
โดยทั่วไป ลูกค้าจะได้รับประโยชน์จากคำอธิบายที่ชัดเจนและขั้นตอนถัดไปที่รองรับ มากกว่ารหัสที่ไม่มีคำอธิบาย เก็บรายละเอียดดิบไว้เพื่อการสนับสนุนและการตรวจสอบ อย่าทำให้สถานะเรียบง่ายจนกลายเป็นคำรับประกันที่หนักแน่นกว่าหลักฐานของเหตุการณ์
แหล่งข้อมูล
- RFC 9110: HTTP Semantics — แหล่งอ้างอิงสำหรับความหมายของรหัสสถานะ HTTP รวมถึง 200 และ 202
- OWASP REST Security Cheat Sheet — คำแนะนำด้านความปลอดภัยที่เกี่ยวข้องกับ endpoint ของ API และ webhook
- 17TRACK Tracking API — แหล่งอ้างอิงผลิตภัณฑ์อย่างเป็นทางการสำหรับตัวเลือกการเชื่อมต่อระบบติดตามที่กล่าวถึง
- 17TRACK API Documentation — แหล่งอ้างอิงอย่างเป็นทางการสำหรับข้อกำหนดการเชื่อมต่อเฉพาะของผู้ให้บริการ สคีมาและคำแนะนำเวิร์กโฟลว์ในคู่มือนี้เป็นเพียงตัวอย่าง ไม่สามารถใช้แทนข้อตกลงดังกล่าว
