ประเภทของข้อผิดพลาด

เราได้จัดหมวดหมู่ข้อผิดพลาดออกเป็นหมวดหมู่กว้างๆ ดังนี้

  • การตรวจสอบสิทธิ์
  • ข้อผิดพลาดที่ลองใหม่ได้
  • การตรวจสอบความถูกต้อง
  • เกี่ยวข้องกับการซิงค์

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

  • ข้อผิดพลาดที่พบบ่อยจะให้รายละเอียดเพิ่มเติมเกี่ยวกับข้อผิดพลาดที่เฉพาะเจาะจง
  • google.rpc.Status ให้รายละเอียดเกี่ยวกับโมเดลข้อผิดพลาดเชิงตรรกะที่ API ใช้
  • รหัสข้อผิดพลาด Canonical แสดงรายการและคำอธิบายของรหัสข้อผิดพลาด Canonical ที่กำหนดโดย gRPC และ HTTP ในบริบทของ Google Ads API

ข้อผิดพลาดในการตรวจสอบสิทธิ์

การตรวจสอบสิทธิ์หมายถึงการที่ผู้ใช้ให้สิทธิ์แอปของคุณในการเข้าถึง Google Ads ในนามของผู้ใช้หรือไม่ การตรวจสอบสิทธิ์จะได้รับการจัดการผ่านข้อมูลเข้าสู่ระบบที่สร้างโดยขั้นตอน OAuth2

สาเหตุที่พบบ่อยที่สุดที่ทำให้เกิดข้อผิดพลาดในการตรวจสอบสิทธิ์จากปัจจัยที่อยู่นอกเหนือการควบคุมของคุณคือ ผู้ใช้ที่ตรวจสอบสิทธิ์ได้เพิกถอนสิทธิ์ที่ให้ไว้กับแอปของคุณเพื่อดำเนินการในนามของผู้ใช้ ตัวอย่างเช่น หากแอปของคุณจัดการบัญชี Google Ads แยกต่างหากสำหรับลูกค้าแต่ละราย และตรวจสอบสิทธิ์แยกกันสำหรับลูกค้าแต่ละรายเมื่อจัดการบัญชีของลูกค้ารายนั้น ลูกค้าจะเพิกถอนสิทธิ์เข้าถึงของแอปได้ทุกเมื่อ ทั้งนี้ขึ้นอยู่กับเวลาที่สิทธิ์เข้าถึงของคุณถูกเพิกถอน API อาจแสดงข้อผิดพลาด AuthenticationError.OAUTH_TOKEN_REVOKED โดยตรง หรือออบเจ็กต์ข้อมูลเข้าสู่ระบบในตัวในไลบรารีของไคลเอ็นต์อาจแสดงข้อยกเว้นโทเค็นถูกเพิกถอน ไม่ว่าในกรณีใด หากแอปมี UI สำหรับลูกค้า แอปอาจขอให้ลูกค้าเปิดขั้นตอน OAuth2 อีกครั้งเพื่อสร้างสิทธิ์ของแอปในการดำเนินการในนามของลูกค้าอีกครั้ง

ในทำนองเดียวกัน หากโปรเจ็กต์ Google Cloud มีเพียงระดับการเข้าถึงแบบทดสอบและพยายามส่งคำขอไปยังบัญชีเวอร์ชันที่ใช้งานจริง (ไม่ใช่แบบทดสอบ) API จะแสดงผลเป็น AuthorizationError ซึ่งค่า enum จะขึ้นอยู่กับเวอร์ชัน API ดังนี้

ข้อผิดพลาดที่ลองใหม่ได้

ข้อผิดพลาดบางอย่าง เช่น TRANSIENT_ERROR หรือ INTERNAL_ERROR อาจบ่งบอกถึงปัญหาชั่วคราวที่อาจแก้ไขได้โดยลองส่งคำขออีกครั้งหลังจากหยุดพักสักครู่

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

สำหรับคำขอที่เริ่มต้นในแบ็กเอนด์ แอปควรลองส่งคำขออีกครั้งโดยอัตโนมัติจนถึงจำนวนครั้งสูงสุดที่กำหนดไว้

เมื่อลองส่งคำขออีกครั้ง ให้ใช้นโยบาย Exponential Backoff ที่มีการกระวนกระวายแบบสุ่ม ตัวอย่างเช่น หากคุณหยุดชั่วคราว 5 วินาทีก่อนลองใหม่ครั้งแรก คุณอาจหยุดชั่วคราว 10 วินาทีหลังจากการลองใหม่ครั้งที่ 2 และ 20 วินาทีหลังจากการลองใหม่ครั้งที่ 3 โดยเพิ่มความล่าช้าแบบสุ่มเล็กน้อยในแต่ละช่วงเวลาเพื่อป้องกันไม่ให้เกิดการลองใหม่พร้อมกันจำนวนมาก Exponential Backoff ช่วยให้มั่นใจได้ว่าคุณไม่ได้เรียกใช้ API บ่อยเกินไป หากข้อผิดพลาดยังคงอยู่หลังจากลองอีกครั้งจนครบจำนวนครั้งแล้ว ให้บันทึก request-id จากการตอบกลับเพื่อแก้ปัญหา

ข้อผิดพลาดเกี่ยวกับการตรวจสอบความถูกต้อง

ข้อผิดพลาดในการตรวจสอบความถูกต้องบ่งชี้ว่าระบบไม่ยอมรับอินพุตสำหรับการดำเนินการ ตัวอย่างเช่น PolicyViolationError, DateError, DateRangeError, StringLengthError และ UrlFieldError

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

แอป Google Ads จำนวนมากจะเก็บรักษาฐานข้อมูลในเครื่องเพื่อจัดเก็บออบเจ็กต์ Google Ads ความท้าทายอย่างหนึ่งของแนวทางนี้คือฐานข้อมูลในเครื่องอาจไม่ซิงค์กับออบเจ็กต์จริงใน Google Ads ตัวอย่างเช่น ผู้ใช้อาจลบกลุ่มโฆษณาใน Google Ads โดยตรง แต่แอปและฐานข้อมูลในเครื่องไม่ทราบถึงการเปลี่ยนแปลงและยังคงเรียกใช้ API ต่อไปเสมือนว่ากลุ่มโฆษณายังคงอยู่ ปัญหาการซิงค์เหล่านี้อาจแสดงเป็นข้อผิดพลาดต่างๆ เช่น DUPLICATE_CAMPAIGN_NAME, DUPLICATE_ADGROUP_NAME, AD_NOT_UNDER_ADGROUP, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD และอื่นๆ อีกมากมาย

สำหรับคำขอที่เริ่มต้นโดยผู้ใช้ กลยุทธ์หนึ่งคือการแจ้งเตือนผู้ใช้เกี่ยวกับปัญหาการซิงค์ที่อาจเกิดขึ้น เริ่มงานที่ดึงข้อมูลคลาสที่เกี่ยวข้องของออบเจ็กต์ Google Ads และอัปเดตฐานข้อมูลในเครื่องทันที จากนั้นแจ้งให้ผู้ใช้รีเฟรช UI

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

ถัดไป
ทำความเข้าใจข้อผิดพลาดของ API