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:
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.
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. Theo mặc định, tính năng thanh toán không cần đăng nhập và email thay thế được hỗ trợ cho các lượt đặt phòng không tính phí.
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.
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.
- Trả về mã trạng thái HTTP được đặt thành
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ộtCreateBookingRequest
lần thứ hai (với cùng mộtidempotency_token
), thì bạn phải trả về cùng mộtCreateBookingResponse
. 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.