เอกสาร API ของ UPS Tracking: 7 ฟีเจอร์สำคัญที่นักพัฒนาควรรู้
เอกสาร UPS tracking API มีประโยชน์มากที่สุดเมื่อช่วยให้นักพัฒนาสามารถเปลี่ยนจากหมายเลขติดตามไปสู่ประสบการณ์แสดงสถานะการจัดส่งที่เชื่อถือได้ ประเด็นสำคัญ 7 ด้านที่ควรตรวจสอบ ได้แก่ การยืนยันตัวตน คำขอติดตาม โครงสร้างการตอบกลับ ประวัติเหตุการณ์ การจัดการข้อผิดพลาด ข้อจำกัดด้านการปฏิบัติงาน และการทดสอบ UPS มีแพลตฟอร์มนักพัฒนาของตนเองสำหรับการเชื่อมต่อโดยตรงกับ UPS ขณะที่บริการหลายผู้ให้บริการขนส่ง เช่น 17TRACK Tracking API อาจเหมาะสมกว่าเมื่อการเชื่อมต่อครั้งเดียวต้องรองรับ UPS และผู้ให้บริการขนส่งรายอื่น
การใช้งานที่เหมาะสมขึ้นอยู่กับระบบที่คุณกำลังสร้าง ผู้ค้าปลีกอาจต้องการอัปเดตการจัดส่งในหน้าคำสั่งซื้อ ทีมคลังสินค้าอาจต้องการการแจ้งเตือนข้อยกเว้น และแพลตฟอร์มระดับองค์กรอาจต้องการข้อมูลติดตามที่ปรับมาตรฐานแล้วจากผู้ให้บริการขนส่งหลายราย การอ่านเอกสารโดยพิจารณาจากกรณีการใช้งานเหล่านี้จะช่วยป้องกันข้อผิดพลาดทั่วไป นั่นคือการถือว่าการตอบกลับ API ที่สำเร็จเท่ากับโซลูชันการมองเห็นสถานะการจัดส่งที่สมบูรณ์
เอกสาร UPS tracking API ควรช่วยตอบคำถามอะไรได้บ้าง
ก่อนเขียนโค้ด ควรทำความชัดเจนใน 4 คำถามต่อไปนี้:
- คุณกำลังเชื่อมต่อเฉพาะ UPS หรือระบบจะติดตามผู้ให้บริการขนส่งหลายราย?
- คุณต้องการสถานะปัจจุบันของพัสดุ ประวัติการสแกนทั้งหมด หรือทั้งสองอย่าง?
- แอปพลิเคชันของคุณจะขออัปเดตตามต้องการ รับการแจ้งเตือน หรือใช้ทั้งสองรูปแบบ?
- ลูกค้าและทีมงานภายในควรเห็นอะไรเมื่อการจัดส่งล่าช้า จัดส่งแล้ว ถูกส่งคืน หรือยังไม่พบข้อมูล?
เอกสาร UPS เป็นแหล่งข้อมูลหลักสำหรับข้อมูลรับรองปัจจุบัน การดำเนินการที่รองรับ ข้อกำหนดของคำขอ ฟิลด์ในการตอบกลับ และเงื่อนไขการเข้าถึงเชิงพาณิชย์ รายละเอียดเหล่านี้อาจเปลี่ยนแปลงตามผลิตภัณฑ์ API รูปแบบบัญชี หรือเวอร์ชันของแพลตฟอร์มนักพัฒนา ดังนั้นโค้ดที่ใช้งานจริงควรอ้างอิงพอร์ทัลนักพัฒนา UPS ปัจจุบัน แทนการพึ่งพาตัวอย่างโค้ดเก่า
7 คุณสมบัติสำคัญที่นักพัฒนาควรเข้าใจ
1. การยืนยันตัวตนและการเข้าถึงแอปพลิเคชัน
การยืนยันตัวตนเป็นคุณสมบัติสำคัญในทางปฏิบัติประการแรก เพราะเป็นตัวกำหนดว่าแอปพลิเคชันจะยืนยันตัวตนและขอสิทธิ์เรียกใช้ API ได้อย่างไร เอกสารสำหรับนักพัฒนา UPS ระบุขั้นตอนปัจจุบันในการลงทะเบียนแอปพลิเคชัน สร้างข้อมูลรับรอง ขอสิทธิ์เข้าถึง และจัดการโทเค็น เอกสารอธิบายการเข้าถึง UPS APIs ที่ใช้ OAuth แต่ก่อนเริ่มใช้งาน นักพัฒนาควรตรวจสอบ grant flow, scopes, อายุของโทเค็น และข้อกำหนดของสภาพแวดล้อมในพอร์ทัลปัจจุบัน
เก็บข้อมูลรับรองไว้ฝั่งเซิร์ฟเวอร์ ไม่ควรฝังข้อมูลเหล่านี้ไว้ใน JavaScript ของเบราว์เซอร์ ไฟล์ build ของมือถือ พื้นที่เก็บโค้ดสาธารณะ หรือโค้ดหน้าติดตามที่ผู้ใช้มองเห็น สถาปัตยกรรมที่ปลอดภัยกว่าคือการวางบริการแบ็กเอนด์ไว้ระหว่างแอปพลิเคชันที่ลูกค้าใช้งานกับ UPS บริการนี้สามารถยืนยันตัวตนอย่างปลอดภัย บังคับใช้ขีดจำกัดคำขอ บันทึกผลลัพธ์ทางเทคนิคโดยไม่เปิดเผยข้อมูลลับ และส่งคืนเฉพาะข้อมูลการจัดส่งที่ส่วนหน้า需要
ควรแยกข้อมูลรับรองสำหรับการพัฒนาออกจากข้อมูลรับรองสำหรับการใช้งานจริง หากแพลตฟอร์ม UPS รองรับสภาพแวดล้อมแยกกัน รายการตรวจสอบการนำระบบไปใช้งานควรรวมการจัดเก็บข้อมูลลับ การหมุนเวียนข้อมูลรับรอง เจ้าของสิทธิ์การเข้าถึง การจัดการโทเค็นหมดอายุ และการแจ้งเตือนเมื่อความล้มเหลวในการยืนยันตัวตนเริ่มเพิ่มขึ้น
2. คำขอด้วยหมายเลขติดตามและบริบทของผู้ให้บริการขนส่ง
การเชื่อมต่อระบบติดตามต้องมีวิธีที่คาดเดาได้ในการส่งตัวระบุการติดตามและขอข้อมูลการจัดส่ง คำถามสำคัญไม่ได้มีเพียงที่อยู่ของ endpoint แต่ยังรวมถึงรูปแบบหมายเลขติดตามที่ยอมรับ คำขอรองรับหนึ่งหมายเลขหรือหลายหมายเลขหรือไม่ วิธีระบุผู้ให้บริการขนส่ง และ API ตอบกลับอย่างไรเมื่อหมายเลขไม่สมบูรณ์หรือยังไม่เป็นที่รู้จัก
อย่าสันนิษฐานว่าสตริงทุกตัวที่มีลักษณะคล้ายหมายเลขติดตามเป็นของ UPS หากแอปพลิเคชันของคุณรับป้ายกำกับจากระบบจัดส่งหลายระบบ ให้จัดเก็บผู้ให้บริการขนส่งไว้ในฟิลด์แยกต่างหากเมื่อทราบข้อมูล การกำหนดเส้นทางตามผู้ให้บริการช่วยลดการจับคู่ผิดและทำให้การแก้ไขปัญหาง่ายขึ้น อีกทั้งยังเป็นพื้นฐานที่ดีสำหรับการขยายระบบเมื่อธุรกิจเพิ่มผู้ให้บริการรายอื่น
ตรวจสอบข้อมูลนำเข้าก่อนส่งคำขอ แต่หลีกเลี่ยงการตรวจสอบที่เข้มงวดเกินไปจนปฏิเสธตัวระบุที่ถูกต้องเพียงเพราะรูปแบบเปลี่ยนไปหรือเพราะเพิ่งสร้างป้ายกำกับ การตอบกลับจาก API ยังคงเป็นการตรวจสอบที่เชื่อถือได้ที่สุด ให้จัดเก็บค่าต้นฉบับ ค่าที่ปรับมาตรฐานเพื่อใช้ค้นหา ผู้ให้บริการขนส่ง ข้อมูลอ้างอิงคำสั่งซื้อ และเวลาที่สอบถามสำเร็จครั้งล่าสุด
3. โครงสร้างการตอบกลับที่เป็นระบบ
เอกสาร UPS tracking API ที่มีประโยชน์ควรอธิบายว่าข้อมูลการจัดส่งถูกจัดระเบียบอย่างไรและฟิลด์ใดเป็นตัวเลือก นักพัฒนาควรตรวจสอบโมเดลการตอบกลับสำหรับข้อมูลระบุการจัดส่ง สถานะปัจจุบัน คำอธิบายสถานะ เวลาการสแกน สถานที่ เวลาคาดว่าจะจัดส่ง ข้อมูลบริการ และรายละเอียดระดับพัสดุ การไม่มีฟิลด์ไม่ได้หมายความเช่นเดียวกับฟิลด์ที่มีค่าว่าง และทั้งสองกรณีไม่ควรถูกตีความโดยอัตโนมัติว่าเป็นการจัดส่งที่ล้มเหลว
สร้างโมเดลภายในที่ปรับมาตรฐานแล้ว แทนการผูกแอปพลิเคชันทั้งหมดเข้ากับชื่อฟิลด์เฉพาะของผู้ให้บริการโดยตรง ตัวอย่างเช่น ฐานข้อมูลของคุณอาจมีตัวระบุการจัดส่ง ผู้ให้บริการขนส่ง สถานะปัจจุบัน เวลาของเหตุการณ์ล่าสุด เวลาจัดส่งโดยประมาณ เวลาจัดส่งสำเร็จ รหัสข้อยกเว้น และข้อมูล payload ดิบจากผู้ให้บริการ ฟิลด์ที่ปรับมาตรฐานแล้วรองรับการรายงานและส่วนติดต่อผู้ใช้ ส่วน payload ดิบรองรับการตรวจสอบย้อนหลังและการเปลี่ยนแปลงการจับคู่ในอนาคต
เก็บรักษา timestamp พร้อม offset หรือข้อมูลเขตเวลาหากมีการส่งมา การแสดงการสแกนจากสถานที่หนึ่งเสมือนว่าเกิดขึ้นตามเวลาท้องถิ่นของผู้ดู อาจทำให้เรื่องราวการจัดส่งสับสนได้ เช่นเดียวกัน อย่าแปลงสถานะโดยละเอียดของผู้ให้บริการให้เป็นป้ายกำกับที่ง่ายขึ้นจนกว่าจะมีการบันทึกกฎทางธุรกิจไว้อย่างชัดเจน
4. ประวัติการสแกนและการตีความสถานะ
คุณค่าของ UPS tracking มักอยู่ที่ลำดับเหตุการณ์มากกว่าป้ายกำกับสถานะปัจจุบันเพียงรายการเดียว พัสดุอาจผ่านการสร้างป้ายกำกับ การรับพัสดุ การขนส่ง การสแกนเมื่อมาถึง เหตุการณ์ข้อยกเว้น เหตุการณ์กำลังนำจ่าย และการจัดส่งสำเร็จ การเชื่อมต่อที่ใช้งานได้ควรจัดเก็บเหตุการณ์ตามลำดับและเก็บคำอธิบายต้นฉบับไว้เมื่อเป็นไปได้
การจับคู่สถานะต้องอาศัยดุลยพินิจด้านเนื้อหาและการปฏิบัติงาน “อยู่ระหว่างการขนส่ง” อาจครอบคลุมหลายขั้นตอน ขณะที่ “ข้อยกเว้น” อาจต้องมีคำอธิบายที่เฉพาะเจาะจงกว่าชื่อสถานะ แอปพลิเคชันของคุณควรแยกอย่างน้อยระหว่างการเคลื่อนย้ายตามปกติ กิจกรรมการจัดส่ง จัดส่งแล้ว ข้อยกเว้น ส่งคืน และสถานะที่ยังไม่สามารถระบุได้ การจับคู่ที่แน่นอนต้องอ้างอิงฟิลด์และรหัสที่ UPS ระบุไว้ ไม่ใช่สมมติฐานจากคำอธิบายภาษาอังกฤษเพียงอย่างเดียว
สำหรับหน้าที่ลูกค้าใช้งาน ให้แสดงเหตุการณ์ล่าสุดที่มีความหมาย เวลา และคำอธิบายสั้น ๆ สำหรับการปฏิบัติงานภายใน ให้เก็บประวัติเหตุการณ์ทั้งหมดและถ้อยคำต้นฉบับของผู้ให้บริการไว้ วิธีนี้ช่วยให้เจ้าหน้าที่สนับสนุนตรวจสอบข้อร้องเรียนได้โดยไม่ต้องขอให้ลูกค้าบอกข้อมูลที่ระบบได้รับแล้วซ้ำ
5. เวลาจัดส่งโดยประมาณและการจัดการข้อยกเว้น
นักพัฒนามักให้ความสำคัญกับเส้นทางการทำงานที่ราบรื่น แต่เวลาจัดส่งโดยประมาณและข้อยกเว้นต่างหากที่กำหนดว่าข้อมูลติดตามจะมีประโยชน์ในทางปฏิบัติหรือไม่ การจัดส่งอาจไม่มีเวลาประมาณการ เวลาประมาณการอาจเปลี่ยนแปลง หรือข้อยกเว้นอาจขัดจังหวะการเคลื่อนย้ายตามปกติชั่วคราว ควรตรวจสอบเอกสารสำหรับฟิลด์และเงื่อนไขที่ใช้แทนกรณีเหล่านี้
อย่าแสดงเวลาประมาณการเป็นการรับประกัน เว้นแต่ข้อกำหนดการให้บริการ UPS ที่เกี่ยวข้องจะรองรับการตีความดังกล่าวอย่างชัดเจน ในส่วนติดต่อผู้ใช้ ให้ระบุว่าเป็นเวลาประมาณการและแสดงวันที่หรือช่วงเวลาให้ตรงตามข้อมูล หาก API ไม่ส่งเวลาประมาณการ ให้แสดงข้อความเป็นกลาง เช่น “ขณะนี้ยังไม่มีเวลาจัดส่งโดยประมาณ” แทนการคิดขึ้นเองจากกฎเวลาขนส่งทั่วไป
เวิร์กโฟลว์ข้อยกเว้นควรกำหนดไว้อย่างชัดเจน ตัดสินใจว่าข้อยกเว้นใหม่จะส่งผลให้มีอีเมล งานสำหรับแผนกช่วยเหลือ การดำเนินการจัดการคำสั่งซื้อ หรือเพียงการเปลี่ยนสถานะ เพิ่มการป้องกันข้อมูลซ้ำเพื่อไม่ให้การ polling ซ้ำส่งการแจ้งเตือนเดิมหลายครั้ง กฎที่ใช้ได้จริงคือเปรียบเทียบตัวระบุเหตุการณ์ หรือชุดค่าคงที่ของเวลาเหตุการณ์ สถานะ และคำอธิบาย ก่อนสร้างการแจ้งเตือนใหม่
6. ข้อผิดพลาด การลองใหม่ และข้อจำกัดด้านการปฏิบัติงาน
ควรอ่านเอกสาร API ในฐานะข้อตกลงด้านการปฏิบัติงาน ไม่ใช่เพียงรายการตัวอย่างที่สำเร็จ นักพัฒนาจำเป็นต้องเข้าใจข้อผิดพลาดด้านการยืนยันตัวตน คำขอไม่ถูกต้อง หมายเลขติดตามที่ไม่รู้จัก บริการขัดข้องชั่วคราว timeout และการตอบกลับเมื่อถึงขีดจำกัดอัตราการใช้งาน แต่ละประเภทควรมีการตอบสนองที่แตกต่างกัน
- ความล้มเหลวในการยืนยันตัวตนควรสร้างการแจ้งเตือนทางวิศวกรรมและไม่ควรลองใหม่อย่างไม่สิ้นสุด
- ข้อผิดพลาดในการตรวจสอบควรถูกบันทึกพร้อมบริบทที่เพียงพอสำหรับแก้ไขคำขอ
- ความล้มเหลวชั่วคราวอาจลองใหม่ด้วย exponential backoff และกำหนดจำนวนครั้งสูงสุด
- หมายเลขติดตามที่ไม่รู้จักหรือเพิ่งสร้างใหม่อาจตรวจสอบอีกครั้งภายหลัง แต่ไม่ควรถูกจัดประเภทว่าสูญหาย
- การตอบกลับเมื่อถึง rate limit ควรทำให้ตาราง polling ช้าลงและเคารพข้อจำกัดที่ระบุในเอกสาร UPS ปัจจุบัน
ใช้ timeout, circuit breaker, ตัวระบุคำขอ และ structured logs จัดเก็บสถานะการตอบกลับจากผู้ให้บริการ ID การจัดส่งภายใน และ timestamp โดยไม่รวม access token และข้อมูลส่วนบุคคลที่ไม่จำเป็น หากเอกสารระบุ response headers หรือคำแนะนำในการลองใหม่ ให้ปฏิบัติตามคำแนะนำเหล่านั้นแทนการใช้นโยบายทั่วไป
7. การทดสอบ การติดตามตรวจสอบ และความพร้อมใช้งานจริง
การเชื่อมต่อ tracking API ควรทดสอบกับหมายเลขติดตามที่สำเร็จมากกว่าหนึ่งรายการ สร้างกรณีทดสอบสำหรับป้ายกำกับที่เพิ่งสร้างใหม่ การจัดส่งที่มีการสแกนหลายครั้ง ข้อยกเว้น พัสดุที่จัดส่งแล้ว หมายเลขที่ไม่รู้จัก ข้อมูลรับรองหมดอายุ คำขอผิดรูปแบบ timeout และเหตุการณ์ซ้ำ ข้อมูลทดสอบและพฤติกรรมของ sandbox ที่แน่นอนต้องยืนยันในสภาพแวดล้อมนักพัฒนา UPS เนื่องจากข้อมูลการจัดส่งจริงและสภาพแวดล้อมทดสอบไม่ได้ทำงานเหมือนกันเสมอไป
ติดตามทั้งผลลัพธ์ทางเทคนิคและทางธุรกิจ ตัวชี้วัดทางเทคนิค ได้แก่ ปริมาณคำขอ latency อัตรา timeout ความล้มเหลวในการยืนยันตัวตน อัตราข้อผิดพลาดของผู้ให้บริการ และจำนวนครั้งที่ลองใหม่ ตัวชี้วัดทางธุรกิจ ได้แก่ สัดส่วนการจัดส่งที่มีเหตุการณ์ล่าสุด อายุของการจัดส่งที่ยังไม่ได้รีเฟรชนานที่สุด และจำนวนคำสั่งซื้อที่ได้รับผลกระทบจากข้อยกเว้น บริการอาจมีอัตราข้อผิดพลาด HTTP ต่ำ แต่ยังคงให้ข้อมูลติดตามที่ล้าสมัยได้ หาก polling หรือการประมวลผลเหตุการณ์หยุดทำงาน
ก่อนเปิดใช้งานจริง ให้จัดทำเอกสารเกี่ยวกับวิธีหยุด polling ชั่วคราว หมุนเวียนข้อมูลรับรอง เล่นการตอบกลับที่ล้มเหลวซ้ำ แก้ไขการจับคู่สถานะที่ผิดพลาด และติดต่อฝ่ายสนับสนุน UPS เก็บ payload จากผู้ให้บริการไว้ตามระยะเวลาที่ควบคุม หากจำเป็นต่อการตรวจสอบ และทบทวนข้อกำหนดด้านความเป็นส่วนตัวและการเก็บรักษาข้อมูลร่วมกับผู้รับผิดชอบที่เหมาะสม
การเชื่อมต่อ UPS โดยตรงหรือ multi-carrier API?
การเชื่อมต่อ UPS โดยตรงเป็นตัวเลือกที่เหมาะสมเมื่อขอบเขตมีเพียง UPS ทีมต้องการจัดการโมเดลเฉพาะของผู้ให้บริการ และมีสิทธิ์เข้าถึง UPS API ที่จำเป็น วิธีนี้สามารถให้การทำงานที่สอดคล้องอย่างใกล้ชิดกับคำศัพท์และกระบวนการปฏิบัติงานของ UPS
multi-carrier API อาจเหมาะกับสถาปัตยกรรมมากกว่าเมื่อแอปพลิเคชันเดียวกันต้องติดตามพัสดุจาก UPS ผู้ให้บริการไปรษณีย์ และผู้ให้บริการโลจิสติกส์รายอื่น ควรตรวจสอบ 17TRACK API documentation สำหรับโมเดลการยืนยันตัวตนปัจจุบัน การดำเนินการที่รองรับ โครงสร้างการตอบกลับ พฤติกรรม webhook เงื่อนไขการใช้งาน และความครอบคลุมของผู้ให้บริการ ก่อนตัดสินใจทางเทคนิค คุณค่าของระบบในสถานการณ์นี้ไม่ได้อยู่ที่การทดแทนความจำเป็นในการอ่านเอกสาร แต่อยู่ที่การช่วยให้ทีมพัฒนาประเมินชั้นการเชื่อมต่อเดียวเทียบกับต้นทุนการดูแลการเชื่อมต่อเฉพาะของผู้ให้บริการหลายราย
ทำการเปรียบเทียบด้วย proof of concept ใช้วงจรชีวิตการจัดส่งเดียวกันกับแต่ละตัวเลือก และวัดความพยายามในการพัฒนา ความครบถ้วนของฟิลด์ ความใหม่ของเหตุการณ์ พฤติกรรมการลองใหม่ ข้อกำหนดด้าน webhook หรือ polling ความสามารถในการสังเกตระบบ และงานที่ต้องทำเมื่อผู้ให้บริการเปลี่ยนการตอบกลับ อย่าเลือกผู้ให้บริการเพียงเพราะตัวอย่างคำขอสั้นกว่า ตัวเลือกที่เหมาะสมกว่าคือสิ่งที่รองรับผลลัพธ์ด้านการปฏิบัติงานที่แอปพลิเคชันของคุณต้องส่งมอบ
ลำดับการใช้งานจริง
- กำหนดผลลัพธ์สำหรับผู้ใช้และการปฏิบัติงาน เช่น หน้าติดตามสำหรับลูกค้าหรือคิวข้อยกเว้น
- ยืนยันว่าขอบเขตเป็น UPS เท่านั้นหรือเป็นหลายผู้ให้บริการขนส่ง
- อ่านเอกสารทางการปัจจุบันเกี่ยวกับการยืนยันตัวตน คำขอติดตาม ฟิลด์การตอบกลับ ข้อผิดพลาด ข้อจำกัด และการทดสอบ
- สร้างโมเดลการจัดส่งและเหตุการณ์ที่ไม่ผูกกับผู้ให้บริการรายใดรายหนึ่ง
- ใช้งานการยืนยันตัวตนฝั่งเซิร์ฟเวอร์และการตรวจสอบข้อมูลนำเข้าอย่างปลอดภัย
- จัดเก็บการตอบกลับดิบและฟิลด์ที่ปรับมาตรฐานแล้วแยกจากกัน
- เพิ่ม polling หรือการรับเหตุการณ์พร้อมการป้องกันข้อมูลซ้ำและ backoff
- ทดสอบคำขอปกติ ล่าช้า มีข้อยกเว้น ไม่รู้จัก และล้มเหลว
- เปิดใช้งานจริงพร้อมการติดตามความใหม่ของข้อมูล ความล้มเหลว และการจัดส่งที่ค้างนาน
ลำดับนี้ช่วยป้องกันไม่ให้ API call กลายเป็นการออกแบบทั้งหมด การติดตามเป็นกระบวนการข้อมูลต่อเนื่อง แอปพลิเคชันต้องรับเหตุการณ์ ตีความอย่างระมัดระวัง แสดงผลอย่างชัดเจน และกู้คืนการทำงานเมื่อผู้ให้บริการหรือเครือข่ายไม่พร้อมใช้งาน
คำถามที่พบบ่อย
ฉันควรอ่านส่วนใดก่อนในเอกสาร UPS tracking API?
เริ่มจากการยืนยันตัวตนและการดำเนินการติดตาม จากนั้นตรวจสอบข้อกำหนดของคำขอ ฟิลด์การตอบกลับ พฤติกรรมข้อผิดพลาด ข้อจำกัดการใช้งาน และคำแนะนำการทดสอบ ส่วนเหล่านี้จะบอกว่า API สอดคล้องกับโมเดลความปลอดภัยและข้อกำหนดข้อมูลของคุณหรือไม่ ก่อนที่คุณจะลงทุนกับการเชื่อมต่อเต็มรูปแบบ
ฉันสามารถใช้ UPS tracking API สำหรับหน้าติดตามที่ลูกค้าใช้งานได้หรือไม่?
ได้ API สามารถให้ข้อมูลสำหรับหน้าที่ลูกค้าใช้งาน แต่หน้าดังกล่าวควรให้บริการผ่านแบ็กเอนด์ของคุณ แทนการเปิดเผยข้อมูลรับรอง API ในเบราว์เซอร์ ออกแบบหน้าให้แยกสถานะปัจจุบัน ประวัติการสแกน เวลาประมาณการ และข้อยกเว้นอย่างชัดเจน และหลีกเลี่ยงการแสดงเวลาประมาณการเป็นการรับประกัน
ควร polling หมายเลขติดตามอย่างต่อเนื่องหรือไม่?
ไม่จำเป็น ความถี่ของ polling ควรสอดคล้องกับขั้นตอนของการจัดส่ง ความเร่งด่วนทางธุรกิจ ข้อจำกัดการใช้งานที่ระบุไว้ และการมีตัวเลือกแบบอิงเหตุการณ์หรือไม่ ใช้ backoff กับการจัดส่งที่ไม่มีการเปลี่ยนแปลง และหยุดหรือลด polling หลังจัดส่งสำเร็จหรือมีสถานะส่งคืนที่สิ้นสุด
หมายเลขติดตามที่ไม่รู้จักแตกต่างจากพัสดุสูญหายอย่างไร?
หมายเลขติดตามที่ไม่รู้จักหมายความว่าคำขอปัจจุบันไม่ได้ส่งผลลัพธ์การจัดส่งที่ระบบรู้จัก อาจเพิ่งสร้างขึ้น กรอกไม่ถูกต้อง ถูกส่งไปยังผู้ให้บริการผิดราย หรือไม่พร้อมใช้งานชั่วคราว ไม่ควรระบุว่าสูญหายโดยไม่มีขั้นตอนทางธุรกิจแยกต่างหากและหลักฐานสนับสนุน
เมื่อใดจึงควรพิจารณา multi-carrier tracking API?
ควรพิจารณาเมื่อแอปพลิเคชันต้องรองรับผู้ให้บริการหลายราย หรือเมื่อการดูแลการยืนยันตัวตน โครงสร้างข้อมูล การจับคู่สถานะ และนโยบายข้อผิดพลาดแยกกันจะสร้างภาระด้านการปฏิบัติงานอย่างมาก เปรียบเทียบผู้ให้บริการด้วยสถานการณ์การจัดส่งจริง และตรวจสอบข้อมูลผู้ให้บริการและคุณสมบัติปัจจุบันจากเอกสารทางการ
แหล่งข้อมูล
- UPS Developer Portal — จุดเข้าถึงอย่างเป็นทางการสำหรับผลิตภัณฑ์ UPS API การตั้งค่าแอปพลิเคชัน การยืนยันตัวตน และแหล่งข้อมูลสำหรับนักพัฒนา
- UPS Tracking — บริการติดตาม UPS อย่างเป็นทางการและแหล่งอ้างอิงคำศัพท์
- 17TRACK Tracking API — หน้าผลิตภัณฑ์อย่างเป็นทางการสำหรับประเมินการเชื่อมต่อระบบติดตามหลายผู้ให้บริการ
- 17TRACK API Documentation — เอกสารสำหรับนักพัฒนาอย่างเป็นทางการเกี่ยวกับรายละเอียด API ปัจจุบันและข้อกำหนดการเชื่อมต่อ
