Bạn cần thiết lập một máy chủ đặt trước để cho phép Trung tâm hành động thực hiện lệnh gọi lại nhằm thay mặt bạn tạo và cập nhật lượt đặt trước.
- Quy trình triển khai chuẩn. Việc này cho phép Trung tâm hành động thay mặt người dùng tạo cuộc hẹn, đặ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 máy chủ 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. Việc này cho phép Google gửi các 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 trước hộp cát hoặc phát triển có thể kết nối với môi trường hộp cát của Actions Center. Chỉ chuyển sang môi trường sản xuất sau khi máy chủ hộp cát đã được kiểm thử đầy đủ.
Phương thức
Đối với mỗi loại máy chủ đặt phòng, bạn phải sử dụng một nhóm phương thức API khác nhau. Bạn có thể tuỳ ý 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 đây cho thấy các phương thức cho từng cách triển khai và bao gồm những đườ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 |
|---|---|
| HealthCheck | TẢI /v3/HealthCheck/ |
| BatchAvailabilityLookup | POST /v3/BatchAvailabilityLookup/ |
| CreateBooking | POST /phiên bản 3/Tạo yêu cầu đặt chỗ/ |
| UpdateBooking | POST /v3/UpdateBooking/ |
| GetBookingStatus | POST /v3/GetBookingStatus/ |
| ListBookings | POST /v3/ListBookings/ |
Tài nguyên API
Thông tin đặt chỗ
Các loại tài nguyên sau được dùng trong phương thức triển khai chuẩn:
- Khe: Một vùng khoảng không quảng cáo.
- Lượt đặt trước: Cuộc hẹn cho một vùng khoảng không quảng cáo.
Quy trình: 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 tiêu chuẩn.
Khi người dùng đặt lịch hẹn, Google sẽ gửi cho bạn họ tên, 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à lượt thanh toán không cần đăng nhập vì Trung tâm hành động 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 rằng lượt đặt trước cuối cùng giống với lượt đặt trước của người bán trong hệ thống đặt trước của bạn.
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, nên máy chủ của bạn cần phải có chứng chỉ TLS hợp lệ khớp với tên DNS của máy chủ. Để giúp thiết lập máy chủ, bạn nên sử dụng một 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 gửi đến máy chủ đặt phòng của bạn sẽ được xác thực bằng quy trình xác thực cơ bản HTTP. 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 phòng trên trang Cấu hình máy chủ đặt phòng trong Cổng đối tác. Bạn phải xoay vòng mật khẩu 6 tháng một lần.
Ví dụ về cách triển khai bộ xương
Để bắt đầu, hãy xem các bộ khung mẫu sau đây của máy chủ đặt phòng được viết cho khung Node.js và Java:
- Bộ khung Node.js js-maps-booking-rest-server-v3-skeleton
- Bộ khung Java java-maps-booking-rest-server-v3-skeleton
Các máy chủ này đã loại bỏ các phương thức REST.
Yêu cầu
Lỗi HTTP và lỗi logic nghiệp vụ
Khi phần phụ trợ của bạn xử lý các yêu cầu HTTP, hai loại lỗi có thể xảy ra.
- Lỗi liên quan đến cơ sở hạ tầng hoặc dữ liệu không chính xác
- Trả về những lỗi này cho máy khách kèm theo mã lỗi HTTP 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
200OK và chỉ định lỗi logic nghiệp vụ trong nội dung phản hồi. Có các loại lỗi logic nghiệp vụ khác nhau tuỳ theo cách triển khai máy chủ.
- Trả về mã trạng thái HTTP được đặt thành
Đối với quy trình triển khai Tiêu chuẩn, các lỗi logic nghiệp vụ có thể xảy ra sẽ được ghi lại trong phần Lỗi đặt trước và được trả về trong phản hồi HTTP. Bạn có thể gặp lỗi logic nghiệp vụ khi tạo hoặc cập nhật mộ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_UNAVAILABLEsẽ được dùng nếu khe được yêu cầu không còn nữa.PAYMENT_ERROR_CARD_TYPE_REJECTEDđược sử dụng nếu loại thẻ tín dụng đã cung cấp không được chấp nhận.
Tính không xác định
Hoạt động 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. Vì lý do này, tất cả các phương thức có trạng thái thay đổi đều phải không thay đổi giá trị:
CreateBookingUpdateBooking
Đối với mọi thông báo yêu cầu ngoại trừ UpdateBooking, mã thông báo giá trị nhận dạng sẽ được đưa vào để xác định riêng biệt yêu cầu. Điều này cho phép bạn phân biệt giữa lệnh gọi REST được thử lại, với ý định tạo một yêu cầu duy nhất và hai yêu cầu riêng biệt.
UpdateBooking được xác định riêng biệt theo mã mục đặt phòng tương ứng, do đó, sẽ không có mã thông báo xác định giá trị nhận dạng nào được đưa vào yêu cầu của họ.
Sau đây là một số ví dụ về cách máy chủ đặt chỗ xử lý trường hợp không thay đổi:
Phản hồi HTTP
CreateBookingthành công sẽ bao gồm yêu cầu đặt phòng đã tạo. Trong một số trường hợp, khoản thanh toán sẽ được xử lý trong quy trình đặt phòng. Nếu nhận được cùng mộtCreateBookingRequestlần thứ hai (với cùng mộtidempotency_token) thì hệ thống 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
CreateBookingkhông thành công và yêu cầu tương tự được gửi lại, thì phần phụ trợ của bạn sẽ thử lại trong trường hợp này.
Yêu cầu về tính không xác định áp dụng cho tất cả phương thức thay đổi trạng thái.