ขั้นตอนที่ 5: ใช้การอัปเดต API แบบเรียลไทม์

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

การอัปเดตแบบเรียลไทม์และฟีดของ API

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

แม้ว่าการอัปเดต API จะใช้เพื่ออัปเดตข้อมูลใดก็ตามที่ฟีดให้ เช่น ข้อมูลเกี่ยวกับผู้ขายและบริการ แต่โดยทั่วไปแล้วจะใช้เพื่ออัปเดตข้อมูลความพร้อมจำหน่ายเท่านั้น

API การอัปเดตแบบเรียลไทม์ที่จําเป็น

Real-time update (RTU) API
BookingNotification ต้องระบุ ส่ง RTU ของ BookingNotification ทุกครั้งที่มีการเปลี่ยนแปลงการจอง (เช่น การแก้ไขหรือการยกเลิก)
ความพร้อมให้บริการแทนที่ RTU ต้องระบุตามเงื่อนไข[1] ส่ง RTU แทนที่แบบเป็นกลุ่มหรือแทนที่รายการเดียวเพื่อส่งการอัปเดตความพร้อมจำหน่ายสินค้าคงคลัง การเปลี่ยนแปลงอาจใช้เวลาหลายนาทีจึงจะมีผล
RTU ของผู้ขาย ไม่บังคับ ส่ง RTU ของผู้ขายหากต้องการทําการเปลี่ยนแปลงข้อมูลผู้ขายแบบเรียลไทม์ การเปลี่ยนแปลงอาจใช้เวลาหลายชั่วโมงจึงจะมีผล
บริการ RTU ไม่บังคับ ส่ง RTU ของบริการหากต้องการทําการเปลี่ยนแปลงข้อมูลบริการแบบเรียลไทม์ กรณีการใช้งานที่พบบ่อยคือ หากราคาบริการผันผวนอย่างมากในระหว่างวัน เราขอแนะนำให้ใช้ RTU ของบริการเพื่อหลีกเลี่ยงการสั่งซื้อที่ไม่สำเร็จเนื่องจากราคาไม่ตรงกัน การเปลี่ยนแปลงอาจใช้เวลาหลายชั่วโมงจึงจะมีผล

Availability Replace API RTU

ใช้ Availability Replace API เพื่ออัปเดตความพร้อมจำหน่ายใน Use Case ต่อไปนี้

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

ดูข้อมูลเพิ่มเติมได้ที่แหล่งข้อมูลต่อไปนี้

Booking Notification API RTU

Booking Notification API จะแจ้งให้ Google ทราบเกี่ยวกับการอัปเดตการจองที่มีอยู่ เมื่อส่งข้อมูลอัปเดตเกี่ยวกับการยกเลิก ให้ส่งเฉพาะข้อมูลที่จำเป็นในคำขอพร้อมพารามิเตอร์การค้นหา updateMask มีตัวอย่างดังต่อไปนี้

Request:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/<PARTNER_ID>/bookings/<BOOKING_ID>?updateMask=status

Body:
{"name":"partners/<PARTNER_ID>/bookings/<BOOKING_ID>", "status":"CANCELED"}

การเข้าถึง API

สร้างบัญชีบริการ

ใช้แท็บข้อมูลเข้าสู่ระบบในคอนโซล Google API เพื่อสร้างบัญชีบริการ เก็บคีย์ส่วนตัวในรูปแบบ JSON ไว้ในที่ปลอดภัย เมื่อสร้างบัญชี คุณจะมีตัวเลือกในการตั้งค่าบทบาทเป็น "เจ้าของ"

ตรวจสอบสิทธิ์ Maps Booking API

หลังจากสร้างบัญชีบริการแล้ว ให้ตรวจสอบสิทธิ์ API ต่อไปนี้

  • Google Maps Booking API
  • Google Maps Booking API (นักพัฒนาซอฟต์แวร์)

ดูคำแนะนำแบบทีละขั้นตอนได้ที่บทแนะนำการตรวจสอบสิทธิ์ด้วย Maps Booking API

ใช้การเรียก RESTful หรือดาวน์โหลดไลบรารีของไคลเอ็นต์

เราขอแนะนำให้คุณเรียกใช้ RESTful กับ Maps Booking API โดยตรงด้วยเพย์โหลด JSON ดูข้อมูลเพิ่มเติมได้ที่เอกสารประกอบ REST API

คุณใช้ไลบรารีของไคลเอ็นต์เพื่อเชื่อมต่อกับ API ได้ด้วย

ภาษา ลิงก์ดาวน์โหลด
Java ไลบรารีของไคลเอ็นต์ Java ดูข้อมูลเพิ่มเติมได้ที่วิธีการสำหรับไคลเอ็นต์ Java

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

ดึงข้อมูลเอกสารการค้นพบ

สําหรับไลบรารีของไคลเอ็นต์บางรายการ เช่น Ruby คุณจะต้องดึงข้อมูลเอกสาร Discovery สําหรับ API ซึ่งจะอธิบายเมธอดและพารามิเตอร์ของ API

ใช้คำสั่งต่อไปนี้เพื่อดึงข้อมูลเอกสาร Discovery

curl -s -o 'mapsbooking_rest' 'https://mapsbooking.googleapis.com/$discovery/rest?version=v1alpha'

ดูข้อมูลเพิ่มเติมเกี่ยวกับการเข้าถึง API จาก Ruby ได้ที่ลิงก์ต่อไปนี้ Ruby API Client และ Ruby Auth Library

เรียก API แบบมีสิทธิ์

เมื่อเรียก API โปรดดูการเตรียมการเรียก API ที่มีสิทธิ์เพื่อให้สิทธิ์บัญชีบริการด้วยคีย์ส่วนตัวและขอบเขต OAuth ต่อไปนี้ https://www.googleapis.com/auth/mapsbooking

โควต้า API

การอัปเดต API มีโควต้า 1,500 คำขอทุกๆ 60 วินาที หรือ 25 คำขอต่อวินาทีโดยเฉลี่ย เมื่อใช้โควต้าเกิน (ซึ่งอาจเกิดขึ้นเมื่อคุณไม่ได้เพิ่มหมายเลขโปรเจ็กต์ Google Cloud ที่ถูกต้องในพอร์ทัลพาร์ทเนอร์) Google จะตอบกลับด้วยข้อความแสดงข้อผิดพลาดต่อไปนี้

{
  "error": {
    "code": 429,
    "message": "Insufficient tokens for quota ...",
    "status": "RESOURCE_EXHAUSTED",
    "details": [...]
  }
}

วิธีแก้ปัญหานี้คือให้ลองเรียกใช้อีกครั้งเป็นระยะๆ ที่นานขึ้นเรื่อยๆ จนกว่าจะสำเร็จ หากคุณใช้โควต้าของ ReplaceServiceAvailability หมดเป็นประจำ ให้เปลี่ยนไปใช้ BatchReplaceServiceAvailabily เพื่อลดจำนวนการเรียก API วิธีนี้ช่วยให้คุณอัปเดตบริการหลายรายการได้ในคําเรียก API ครั้งเดียว

ปลายทางของแซนด์บ็อกซ์และเวอร์ชันที่ใช้งานจริง

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

ปลายทางเวอร์ชันที่ใช้งานจริง: https://mapsbooking.googleapis.com/

ปลายทางของแซนด์บ็อกซ์: https://partnerdev-mapsbooking.googleapis.com/

ต่อไปนี้เป็นตัวอย่างใน Java ของวิธีเปลี่ยนปลายทาง

    // This block of code is for OAuth and is the same for prod and sandbox.
    GoogleCredential
      .fromStream(new FileInputStream(...))
      .createScoped(Collections.singleton("https://www.googleapis.com/auth/mapsbooking"))

    // This block of code sets the endpoint. This is what you'd change to connect to the sandbox.
    new GoogleMapsBookingAPI.Builder(...)
      .setApplicationName(...)
      .setRootUrl("https://partnerdev-mapsbooking.googleapis.com/") // you add this to change the endpoint to use partnerdev.
      .build()
ก่อนหน้า
ขั้นตอนที่ 4: ติดตั้งใช้งานเซิร์ฟเวอร์การจอง
ถัดไป
ขั้นตอนที่ 6: การทดสอบจากต้นทางถึงปลายทาง