Triển khai máy chủ đặt phòng

Bạn cần đứng lên máy chủ đặt trước để cho phép tính năng Đặt chỗ bằng Google thực hiện lệnh gọi lại để tạo và thay mặt bạn đặt chỗ.

• Chế độ Triển khai chuẩn. Điều này cho phép tính năng Đặt chỗ bằng Google thay mặt người dùng tạo các cuộc hẹn, yêu cầu đặt trước và đặt chỗ với bạn.

Hãy tham khảo tài liệu về Cổng đối tác để tìm hiểu cách định cấu hình kết nối với hộp cát và máy chủ đặt trước phiên bản sản xuất.

Triển khai giao diện API REST

Triển khai giao diện API dựa trên REST. Nhờ đó, Google có thể gửi yêu cầu máy chủ đặt phòng qua HTTP.

Để bắt đầu, hãy thiết lập một máy chủ đặt phòng phát triển hoặc hộp cát có thể kết nối với môi trường hộp cát Đặt trước bằng Google. Chỉ chuyển sang môi trường sản xuất sau khi máy chủ hộp cát được kiểm tra đầy đủ.

Phương pháp

Đối với mỗi loại máy chủ đặt trước, bạn cần có một nhóm phương thức API khác nhau. Nếu muốn, bạn có thể tải định nghĩa dịch vụ xuống ở định dạng proto để bắt đầu triển khai API. Các bảng sau trình bày các phương thức cho mỗi hoạt động triển khai và bao gồm đường liên kết đến các định dạng proto dịch vụ.

Triển khai chuẩn
Định nghĩa dịch vụ tiêu chuẩn Tải tệp định nghĩa dịch vụ proto xuống.

Phương thức	Yêu cầu HTTP
Kiểm tra tình trạng	GET /v3/HealthCheck/
BatchAvailabilitylookup	POST /v3/BatchAvailabilitySession/
Tạo lượt đặt trước	ĐĂNG /v3/Tạo đặt trước/
Cập nhật đặt trước	ĐĂNG /v3/Cập nhật đặt chỗ/
Nhận trạng thái đặt trước	POST /v3/GetBookingStatus/
Danh sách lượt đặt trước	POST /v3/ListBookings/

Tài nguyên API

Đặt dịch vụ

Các loại tài nguyên sau được dùng trong quá trình triển khai chuẩn:

• Vùng: Một khe khoảng không quảng cáo.
• Đặt trước: Cuộc hẹn cho vị trí khoảng không quảng cáo.

Luồng: tạo một lượt đặt trước

Phần này trình bày cách tạo một lượt đặt trước triển khai chuẩn.

Hình 1: Quy trình tạo lượt đặt trước từ một vị trí

Khi người dùng tạo một lượt đặt trước, Google sẽ gửi cho bạn tên, họ, số điện thoại và email của người dùng đó. Theo quan điểm của bạn, lượt đặt phòng này cần được coi là quy trình thanh toán không cần đăng nhập vì tính năng Đặt chỗ bằng Google không thể tra cứu tài khoản của người dùng trong hệ thống của bạn. Đảm bảo lượt đặt phòng cuối cùng có vẻ giống với lượt đặt trước của người bán đến từ hệ thống đặt trước.

Bảo mật và xác thực

Mọi hoạt động giao tiếp với máy chủ đặt phòng đều diễn ra qua HTTPS, vì vậy, máy chủ của bạn phải có chứng chỉ TLS hợp lệ khớp với tên DNS. Để giúp thiết lập máy chủ của bạn, bạn nên sử dụng công cụ xác minh SSL/TLS có sẵn công khai, chẳng hạn như Kiểm tra máy chủ SSL của Qualys.

Tất cả các yêu cầu mà Google thực hiện đối với máy chủ đặt phòng của bạn sẽ được xác thực bằng cơ chế xác thực HTTP cơ bản. Bạn có thể nhập thông tin xác thực cơ bản (tên người dùng và mật khẩu) cho máy chủ đặt trước trên trang Cấu hình máy chủ đặt phòng trong Cổng thông tin đối tác. Mật khẩu phải được xoay vòng 6 tháng một lần.

Lưu ý: Bạn phải đặt tên người dùng và mật khẩu cho Hộp cát và Sản xuất riêng biệt bằng cách sử dụng trình chuyển đổi Môi trường.

Triển khai Bộ xương mẫu

Để bắt đầu, hãy tham khảo các khung mẫu sau đây của máy chủ đặt phòng được viết cho khung Node.js và Java:

• Bộ xương Node.js js-maps-booking-rest-server-v3-skeleton
• Bộ xương Java java-maps-booking-rest-server-v3-skeleton

Các máy chủ này đã loại bỏ phương thức REST.

Yêu cầu

Lỗi HTTP và lỗi logic kinh doanh

Khi phần phụ trợ của bạn xử lý các yêu cầu HTTP, có thể xảy ra hai loại lỗi.

• Lỗi liên quan đến cơ sở hạ tầng hoặc dữ liệu không chính xác
  • Trả về lỗi này cho ứng dụng khách bằng mã lỗi HTTP tiêu chuẩn. Xem danh sách mã trạng thái HTTP đầy đủ.
• Lỗi liên quan đến logic kinh doanh
  • Trả về mã trạng thái HTTP được đặt thành 200 OK và chỉ định lỗi logic kinh doanh trong nội dung phản hồi. Các loại lỗi logic kinh doanh mà bạn có thể gặp phải là khác nhau đối với các loại triển khai máy chủ khác nhau.

Trong quá trình triển khai Chuẩn, các lỗi logic kinh doanh có thể xảy ra trong Lỗi đặt trước và sẽ được trả về trong phản hồi HTTP. Bạn có thể gặp phải lỗi logic kinh doanh khi tạo hoặc cập nhật tài nguyên. Ví dụ: khi bạn xử lý các phương thức CreateBooking hoặc UpdatingBooking. Một số ví dụ bao gồm, nhưng không giới hạn ở các sản phẩm sau:

• SLOT_UNAVAILABLE sẽ được dùng nếu khe yêu cầu không còn nữa.
• PAYMENT_ERROR_CARD_TYPE_REJECTED sẽ được dùng nếu loại thẻ tín dụng mà bạn cung cấp không được chấp nhận.

Hiệu ứng mạnh

Việc giao tiếp qua mạng không phải lúc nào cũng đáng tin cậy và Google có thể thử lại các yêu cầu HTTP nếu không nhận được phản hồi nào. Vì lý do này, tất cả các phương thức thay đổi trạng thái phải mang tính cố định:

• CreateBooking
• UpdateBooking

Đối với mỗi thông báo yêu cầu, ngoại trừ UpdateBooking, mã thông báo hiệu quả được cung cấp để xác định từng yêu cầu. Điều này cho phép bạn phân biệt giữa lệnh gọi REST đã thử lại với ý định tạo một yêu cầu và hai yêu cầu riêng biệt. UpdateBooking được xác định duy nhất bằng các mã truy cập đặt phòng tương ứng, vì vậy không có mã thông báo bắt buộc nào được đưa vào yêu cầu của họ.

Dưới đây là một số ví dụ về cách máy chủ đặt phòng xử lý trường hợp:

• Phản hồi HTTP CreateBooking thành công bao gồm lượt đặt trước đã tạo. Trong một số trường hợp, quy trình thanh toán sẽ được xử lý trong quy trình đặt phòng. Nếu nhận được cùng một CreateBookingRequest lần thứ hai (với cùng một idempotency_token), thì bạn phải trả về cùng một CreateBookingResponse. Không có lượt đặt phòng thứ hai nào được tạo và người dùng sẽ bị tính phí chính xác một lần, nếu có.

  Xin lưu ý rằng nếu bạn thực hiện CreateBooking không thành công và yêu cầu đó được gửi lại, thì phần phụ trợ sẽ thử lại trong trường hợp này.

Yêu cầu về mức độ hiệu quả áp dụng cho tất cả các phương thức thay đổi trạng thái.