คุณต้องสร้างเซิร์ฟเวอร์การจองเพื่ออนุญาตให้ Actions Center เรียกกลับเพื่อสร้างและอัปเดตการจองในนามของคุณ
- การใช้งานแบบมาตรฐาน การดำเนินการนี้จะอนุญาตให้ศูนย์การดำเนินการสร้างการนัดหมาย การจอง และการจองกับคุณในนามของผู้ใช้ได้
ดูเอกสารประกอบของพอร์ทัลพาร์ทเนอร์เพื่อดูวิธีกำหนดค่าการเชื่อมต่อกับแซนด์บ็อกซ์และเซิร์ฟเวอร์การจองเวอร์ชันที่ใช้งานจริง
ใช้อินเทอร์เฟซ REST API
ใช้อินเทอร์เฟซ API ที่อิงตาม REST ซึ่งจะช่วยให้ Google ส่งคำขอเซิร์ฟเวอร์การจองผ่าน HTTP ได้
ในการเริ่มต้น ให้ตั้งค่าเซิร์ฟเวอร์การจองของแซนด์บ็อกซ์หรือการพัฒนาที่สามารถเชื่อมต่อกับสภาพแวดล้อมแซนด์บ็อกซ์ของ Actions Center ได้ โปรดย้ายไปยังสภาพแวดล้อมการใช้งานจริงเมื่อทดสอบเซิร์ฟเวอร์แซนด์บ็อกซ์อย่างสมบูรณ์แล้วเท่านั้น
วิธีการ
คุณต้องระบุชุดเมธอด API ที่แตกต่างกันในฝั่งของคุณสำหรับเซิร์ฟเวอร์การจองแต่ละประเภท คุณดาวน์โหลดคำจำกัดความของบริการในรูปแบบโปรโตเพื่อเริ่มต้นใช้งาน API ได้ (ไม่บังคับ) ตารางต่อไปนี้แสดงวิธีการใช้งานแต่ละรายการและมีลิงก์ไปยังรูปแบบโปรโตบริการ
การติดตั้งมาตรฐาน |
---|
คำจำกัดความของบริการมาตรฐาน ดาวน์โหลดไฟล์คำจำกัดความของบริการ Proto |
วิธีการ | คำขอ HTTP |
---|---|
HealthCheck | รับ /v3/การตรวจสอบประสิทธิภาพการทำงาน/ |
BatchAvailabilityLookup | POST /v3/BatchAvailabilityLookup/ |
CreateBooking | POST /v3/CreateBooking/ |
UpdateBooking | POST /v3/UpdateBooking/ |
GetBookingStatus | POST /v3/GetBookingStatus/ |
ListBookings | POST /v3/ListBookings/ |
ทรัพยากร API
การจอง
มีการใช้ทรัพยากรประเภทต่อไปนี้ในการใช้งานมาตรฐาน
ขั้นตอน: สร้างการจอง
ส่วนนี้จะครอบคลุมวิธีสร้างการจองสําหรับการใช้งานมาตรฐาน
![รูปที่ 1: เวิร์กโฟลว์ในการสร้างการจองจากช่อง](https://developers-dot-devsite-v2-prod.appspot.com/static/actions-center/images/rest_api_v3_booking_flow_1.png?authuser=19&hl=th)
เมื่อผู้ใช้สร้างการจอง 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 อาจพบข้อผิดพลาดด้านตรรกะธุรกิจเมื่อมีการสร้างหรืออัปเดตทรัพยากร เช่น เมื่อคุณจัดการเมธอด CreateBooking
หรือ UpdatingBooking
ตัวอย่างอาจรวมถึงแต่ไม่จำกัดเฉพาะผลิตภัณฑ์ต่อไปนี้
- ระบบจะใช้
SLOT_UNAVAILABLE
หากช่องที่ขอไม่พร้อมใช้งานอีกต่อไป - ระบบจะใช้
PAYMENT_ERROR_CARD_TYPE_REJECTED
หากระบบไม่ยอมรับประเภทบัตรเครดิตที่ระบุ
การแสดงถึงตัวตน
การสื่อสารผ่านเครือข่ายอาจไม่น่าเชื่อถือเสมอไป และ Google อาจลองส่งคำขอ HTTP ซ้ำหากไม่ได้รับการตอบกลับ ด้วยเหตุนี้ เมธอดทั้งหมดที่สถานะกลายพันธุ์จะต้องเป็นแบบเดี่ยว ดังนี้
CreateBooking
UpdateBooking
สำหรับข้อความคำขอทุกรายการ ยกเว้น UpdateBooking
ระบบจะรวมโทเค็นการมีตัวตนไว้เพื่อระบุคำขอโดยไม่ซ้ำกัน การดำเนินการนี้จะช่วยให้คุณแยกแยะระหว่างการเรียก REST ที่พยายามซ้ำโดยมีจุดประสงค์ที่จะสร้างคำขอเดียวและคำขอแยกกัน 2 รายการ
UpdateBooking
จะระบุโดยไม่ซ้ำกันตามรหัสรายการการจองตามลำดับ จึงไม่มีโทเค็นการแสดงตัวอยู่ในคำขอ
ตัวอย่างบางส่วนของวิธีที่เซิร์ฟเวอร์การจองจัดการความระบุตัวตนมีดังนี้
การตอบกลับ HTTP
CreateBooking
ที่สำเร็จจะรวมการจองที่สร้างขึ้นด้วย ในบางกรณี ระบบจะประมวลผลการชำระเงินโดยเป็นส่วนหนึ่งของขั้นตอนการจอง หากได้รับCreateBookingRequest
ที่เหมือนกันทุกประการเป็นครั้งที่ 2 (โดยมีidempotency_token
เหมือนกัน) จะต้องแสดงผลCreateBookingResponse
เดียวกัน ไม่มีการสร้างการจองครั้งที่ 2 และระบบจะเรียกเก็บเงินจากผู้ใช้เพียงครั้งเดียว (หากมี)โปรดทราบว่าหากพยายาม
CreateBooking
ไม่สำเร็จและส่งคำขอเดิมอีกครั้ง แบ็กเอนด์ควรลองอีกครั้งในกรณีนี้
ข้อกำหนดด้านการมีตัวตนจะมีผลกับเมธอดทั้งหมดที่เปลี่ยนสถานะ