ใช้เซิร์ฟเวอร์การจอง

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

• การใช้งานมาตรฐาน การดําเนินการนี้จะช่วยให้ "จองกับ Google" สร้างการนัดหมาย การจอง และการจองกับคุณในนามของผู้ใช้ได้

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

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

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

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

วิธีการ

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

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

วิธีการ	คำขอ HTTP
การตรวจสอบประสิทธิภาพการทํางาน	ดาวน์โหลด /v3/HealthCheck/
BatchavailabilityLookup	โพสต์ /v3/BatchavailabilityLookup/
สร้างการจอง	โพสต์ /v3/CreateBooking/
อัปเดตการจอง	โพสต์ /v3/UpdateBooking/
GetBookingStatus	โพสต์ /v3/GetBookingStatus/
BookBook	โพสต์ /v3/ListBookings/

แหล่งข้อมูลเกี่ยวกับ API

การจอง

มีการใช้ทรัพยากรประเภทต่อไปนี้ในการใช้งานมาตรฐาน

• ช่องโฆษณา: ช่องพื้นที่โฆษณา
• การจอง: การนัดหมายสําหรับช่องพื้นที่โฆษณา

โฟลว์: สร้างการจอง

ส่วนนี้จะพูดถึงวิธีสร้างการจองสําหรับการใช้งานมาตรฐาน

รูปที่ 1: เวิร์กโฟลว์สําหรับสร้างการจองจากช่อง

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

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

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

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

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

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

ในการเริ่มต้นใช้งาน โปรดดูตัวอย่างโครงกระดูกของเซิร์ฟเวอร์การจองสําหรับเฟรมเวิร์ก Node.js และ Java

• โครงกระดูก Node.js js-maps-booking-rest-server-v3-skeleton
• Java Skeleton java-maps-booking-rest-server-v3-skeleton

เซิร์ฟเวอร์เหล่านี้เลิกใช้เมธอด REST แล้ว

ข้อกำหนด

ข้อผิดพลาด HTTP และข้อผิดพลาดด้านตรรกะทางธุรกิจ

เมื่อแบ็กเอนด์จัดการคําขอ HTTP ระบบอาจเกิดข้อผิดพลาด 2 ประเภท

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

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

ข้อกําหนดเกี่ยวกับความไม่เข้มงวดมีผลกับวิธีการทั้งหมดที่เปลี่ยนสถานะ