คุณต้องสร้างเซิร์ฟเวอร์การจองเพื่ออนุญาตให้ 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: เวิร์กโฟลว์ในการสร้างคิวรอ](https://developers.google.cn/static/actions-center/images/waitlists/rest_api_v3_waitlist_flow.png?authuser=19&hl=th)
เมื่อผู้ใช้สร้างรายการรอเรียก 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 ออกไป
ข้อกำหนด
ข้อผิดพลาด HTTP และข้อผิดพลาดด้านตรรกะทางธุรกิจ
เมื่อแบ็กเอนด์จัดการคำขอ HTTP อาจเกิดข้อผิดพลาด 2 ประเภท
- ข้อผิดพลาดเกี่ยวกับโครงสร้างพื้นฐานหรือข้อมูลที่ไม่ถูกต้อง
- แสดงข้อผิดพลาดเหล่านี้ไปยังไคลเอ็นต์ด้วยรหัสข้อผิดพลาด HTTP มาตรฐาน ดูรายการรหัสสถานะ HTTP แบบเต็ม
- ข้อผิดพลาดที่เกี่ยวข้องกับตรรกะทางธุรกิจ
- แสดงผลรหัสสถานะ HTTP ที่ตั้งค่าเป็น
200
OK และระบุความล้มเหลวของตรรกะธุรกิจในเนื้อหาการตอบกลับ ประเภทข้อผิดพลาดด้านตรรกะธุรกิจที่คุณอาจพบจะแตกต่างกันไปสำหรับการติดตั้งใช้งานเซิร์ฟเวอร์แต่ละประเภท
- แสดงผลรหัสสถานะ HTTP ที่ตั้งค่าเป็น
สําหรับการผสานรวมคิวรอการจอง ระบบจะบันทึกข้อผิดพลาดด้านตรรกะทางธุรกิจไว้ในข้อผิดพลาดด้านตรรกะทางธุรกิจของคิวรอ และจะแสดงผลในการตอบสนอง 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
ไม่สำเร็จและส่งคำขอเดิมอีกครั้ง แบ็กเอนด์ก็ควรลองอีกครั้งในกรณีนี้
ข้อกำหนดด้านการมีตัวตนจะมีผลกับเมธอดทั้งหมดที่เปลี่ยนสถานะ