ขั้นตอนที่ 3: ติดตั้งใช้งานเซิร์ฟเวอร์การจองคิวรอ

คุณต้องสร้างเซิร์ฟเวอร์การจองเพื่ออนุญาตให้ Actions Center เรียกกลับเพื่อสร้างและอัปเดตการจองในนามของคุณ

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

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

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

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

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

วิธีการ

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

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

วิธีการ	คำขอ HTTP
HealthCheck	รับ /v3/การตรวจสอบประสิทธิภาพการทำงาน/
BatchGetWaitEstimates	POST /v3/BatchGetWaitEstimateds/
CreateWaitlistEntry	POST /v3/CreateWaitEntryEntry/
GetWaitlistEntry	POST /v3/GetWaitlistEntry/
DeleteWaitlistEntry	POST /v3/DeleteWaitEntryEntry/

ทรัพยากร API

คิวรอ

ทรัพยากรต่อไปนี้จะใช้สำหรับการจองตามคิวรอ

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

โฟลว์: สร้างคิวรอ

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

ภาพที่ 2: เวิร์กโฟลว์ในการสร้างคิวรอ

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

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

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

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

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

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

ในการเริ่มต้นใช้งาน โปรดดูโครงกระดูกตัวอย่างต่อไปนี้ของเซิร์ฟเวอร์การจองที่เขียนขึ้นสำหรับเฟรมเวิร์กของ 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 ซ้ำหากไม่ได้รับการตอบกลับ ด้วยเหตุนี้ เมธอดทั้งหมดที่สถานะกลายพันธุ์จะต้องเป็นแบบเดี่ยว ดังนี้

• CreateWaitlistEntry
• DeleteWaitlistEntry

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

ตัวอย่างบางส่วนของวิธีที่เซิร์ฟเวอร์การจองจัดการความระบุตัวตนมีดังนี้

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

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

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