ขั้นตอนที่ 3: ใช้เซิร์ฟเวอร์การจองสำหรับผู้ที่รอซื้อ

คุณต้องตั้งค่าเซิร์ฟเวอร์การจองเพื่อให้ศูนย์การดำเนินการโทรกลับเพื่อสร้างและอัปเดตการจองในนามของคุณ

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

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

ใช้อินเทอร์เฟซ REST API

ใช้อินเทอร์เฟซ API ตาม REST ซึ่งจะช่วยให้ Google ส่งคำขอไปยังเซิร์ฟเวอร์การจองผ่าน HTTP ได้

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

เมธอด

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

การใช้งานคิวรอ
คำจำกัดความของบริการการรอ ดาวน์โหลดไฟล์คําจํากัดความของบริการโปรโต

วิธีการ	คำขอ HTTP
HealthCheck	GET /v3/HealthCheck/
BatchGetWaitEstimates	POST /v3/BatchGetWaitEstimates/
CreateWaitlistEntry	POST /v3/CreateWaitlistEntry/
GetWaitlistEntry	POST /v3/GetWaitlistEntry/
DeleteWaitlistEntry	POST /v3/DeleteWaitlistEntry/

แหล่งข้อมูล API

คิวรอ

ทรัพยากรต่อไปนี้ใช้เพื่อเปิดใช้การจองตามคิวรอ

• WaitEstimate: เวลารอโดยประมาณสำหรับกลุ่มลูกค้าที่เข้าพักและขนาดกลุ่มที่เฉพาะเจาะจง
• WaitlistEntry: รายการของผู้ใช้ในคิวรอ

ขั้นตอน: สร้างรายการคิวรอเรียก

ส่วนนี้จะอธิบายวิธีสร้างการจองสำหรับการผสานรวมคิวรอการจอง

รูปที่ 2: เวิร์กโฟลว์ในการสร้างรายการรอ

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

ความปลอดภัยและการตรวจสอบสิทธิ์

การสื่อสารทั้งหมดกับเซิร์ฟเวอร์การจองจะเกิดขึ้นผ่าน HTTPS ดังนั้นเซิร์ฟเวอร์ของคุณจึงต้องมีใบรับรอง TLS ที่ถูกต้องซึ่งตรงกับชื่อ DNS เราขอแนะนำให้ใช้เครื่องมือยืนยัน SSL/TLS ที่พร้อมให้ใช้งานฟรี เช่น การทดสอบเซิร์ฟเวอร์ SSL ของ Qualys เพื่อช่วยในการตั้งค่าเซิร์ฟเวอร์

คำขอทั้งหมดที่ Google จะส่งไปยังเซิร์ฟเวอร์การจองจะได้รับการตรวจสอบสิทธิ์โดยใช้การตรวจสอบสิทธิ์พื้นฐานของ HTTP คุณสามารถป้อนข้อมูลเข้าสู่ระบบการตรวจสอบสิทธิ์พื้นฐาน (ชื่อผู้ใช้และรหัสผ่าน) สำหรับเซิร์ฟเวอร์การจองได้ในหน้าการกําหนดค่าเซิร์ฟเวอร์การจองภายในพอร์ทัลพาร์ทเนอร์ และต้องเปลี่ยนรหัสผ่านทุก 6 เดือน

หมายเหตุ: คุณต้องตั้งค่าชื่อผู้ใช้และรหัสผ่านสำหรับ Sandbox และเวอร์ชันที่ใช้งานจริงแยกกันโดยใช้ตัวสลับสภาพแวดล้อม

ตัวอย่างการใช้งานโครงร่าง

หากต้องการเริ่มต้นใช้งาน ให้ดูตัวอย่างโครงร่างเซิร์ฟเวอร์การจองต่อไปนี้ซึ่งเขียนขึ้นสำหรับเฟรมเวิร์ก Node.js และ Java

• โครง Node.js js-maps-booking-rest-server-v3-skeleton
• โครงร่าง Java java-maps-booking-rest-server-v3-skeleton

เซิร์ฟเวอร์เหล่านี้มีเมธอด REST ที่เป็นสแต็บ

หมายเหตุ: สําหรับการผสานรวมคิวรอการจอง ให้เปลี่ยนเมธอด REST เป็นเมธอดคิวรอการจองที่จําเป็น

ข้อกำหนด

ข้อผิดพลาด HTTP และข้อผิดพลาดด้านตรรกะทางธุรกิจ

เมื่อแบ็กเอนด์จัดการคำขอ HTTP อาจเกิดข้อผิดพลาด 2 ประเภท

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

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

• ABOVE_MAX_PARTY_SIZE ใช้เมื่อรายการคิวรอที่ขอมีจำนวนมากกว่าจำนวนคนสูงสุดของผู้ขาย
• MERCHANT_CLOSED ใช้เมื่อคิวรอปิดอยู่เนื่องจากผู้ขายปิดไปแล้ว

การทำงานซ้ำ

การสื่อสารผ่านเครือข่ายอาจไม่น่าเชื่อถือเสมอไป และ Google อาจลองส่งคำขอ HTTP อีกครั้งหากไม่ได้รับการตอบกลับ ด้วยเหตุนี้ เมธอดทั้งหมดที่เปลี่ยนแปลงสถานะจึงต้องเป็นแบบ idempotent

• CreateWaitlistEntry
• DeleteWaitlistEntry

สำหรับข้อความคำขอทุกรายการยกเว้น DeleteWaitlistEntry ระบบจะรวมโทเค็นแบบซ้ำกันไม่ได้เพื่อระบุคำขอที่ไม่ซ้ำกัน ซึ่งจะช่วยให้คุณแยกความแตกต่างระหว่างการเรียก REST ที่พยายามอีกครั้งโดยมีเจตนาสร้างคำขอเดียว กับคำขอ 2 รายการแยกกัน DeleteWaitlistEntry ได้รับการระบุตัวตนที่ไม่ซ้ำกันด้วยรหัสรายการในคิวรอตามลำดับ จึงไม่มีโทเค็นแบบซ้ำกันรวมอยู่ในคำขอ

ต่อไปนี้เป็นตัวอย่างบางส่วนของวิธีที่เซิร์ฟเวอร์การจองจัดการการทำงานซ้ำ

• การตอบกลับ HTTP CreateWaitlistEntry ที่สำเร็จจะมีรหัสรายการในคิวรอที่สร้างขึ้น หากได้รับ CreateWaitlistEntryRequest เดียวกันเป็นครั้งที่ 2 (โดยมี idempotency_token เดียวกัน) คุณต้องส่งคืน CreateWaitlistEntryResponse เดียวกัน ระบบจะไม่สร้างรายการรอที่ 2 และไม่แสดงข้อผิดพลาด

  โปรดทราบว่าหากพยายาม CreateWaitlistEntry ไม่สำเร็จและมีการส่งคำขอเดิมอีกครั้ง ในกรณีนี้แบ็กเอนด์ควรลองอีกครั้ง

ข้อกำหนดแบบซ้ำซ้อนมีผลกับเมธอดทั้งหมดที่เปลี่ยนแปลงสถานะ