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

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

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

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

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

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

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

เมธอด

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

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

วิธีการ	คำขอ HTTP
HealthCheck	GET /v3/HealthCheck/
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 เดือน

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

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

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

• CreateBooking
• UpdateBooking

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

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

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

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

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