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

คุณต้องสร้างเซิร์ฟเวอร์การจองเพื่ออนุญาตให้ 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: เวิร์กโฟลว์ในการสร้างการจองจากช่อง

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

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