예약 서버 구현: API v2

예약 서버를 설정하면 Actions Center에서 다음 작업을 할 수 있습니다. 사용자를 대신하여 약속 / 예약 / 예약을 생성합니다.

gRPC를 기반으로 API 인터페이스 구현

참고: 모든 신규 파트너는 gRPC가 아닌 REST API 인터페이스를 사용해야 합니다. API를 제공합니다.

gRPC를 기반으로 API 인터페이스를 구현합니다. 이렇게 하면 Google에서 예약 요청을 보낼 수 있습니다. API 노출 영역 gRPC의 protobuf 기반 IDL

Google은 신규 파트너에게 권장되는 API v2 모음을 구현하도록 요청합니다. 파트너가 수행할 수 있는 작업 URL과 PORT를 선택하여 해당 인프라에 가장 적합한 URL과 PORT를 선택할 수 있습니다.

이 섹션에서는 권장되는 API v2 세트를 소개합니다. API v0을 구현하지 않았습니다. API를 구현한 현재 파트너의 경우 자세한 내용은 Actions Center에 문의하시기 바랍니다.

아래의 proto 형식으로 서비스 정의를 다운로드하여 API 구현입니다.

서비스 다운로드 정의

API 리소스

다음 리소스 유형이 숙지하고 있어야 합니다. 다음과 같습니다.

  • 슬롯: 인벤토리 슬롯
  • 예약: 인벤토리 슬롯에 대한 약속

메서드

다음 API 메서드는 사용자 측에서 구현해야 gRPC 서버:

다음 5가지 메서드는 필수 BookingService RPC 집합을 정의합니다.

// Manages slot availability, leases and bookings for an inventory of
// appointments
service BookingService {
  // Gets availability information for an appointment slot
  rpc CheckAvailability(CheckAvailabilityRequest)
      returns (CheckAvailabilityResponse) {}

  // Creates a booking
  rpc CreateBooking(CreateBookingRequest) returns (CreateBookingResponse) {}

  // Updates an existing booking
  rpc UpdateBooking(UpdateBookingRequest) returns (UpdateBookingResponse) {}

  // Gets status for an existing booking
  rpc GetBookingStatus(GetBookingStatusRequest)
      returns (GetBookingStatusResponse) {}

  // Lists all upcoming bookings for a user
  rpc ListBookings(ListBookingsRequest) returns (ListBookingsResponse) {}
}

과정: 예약 만들기

<ph type="x-smartling-placeholder">
</ph>
그림 1: 예약 생성 슬롯

예약을 생성할 때 Google은 파트너에게 사용자의 이름, 성, 전화번호, 이메일 주소를 입력해야 합니다. 이것은 비회원 결제를 파트너의 시스템에서 사용자의 계정을 조회하는 방법입니다. 최종 예약 예약과 마찬가지로 시스템에서 파트너의 판매자에게 표시되어야 합니다. 이는 파트너의 예약 시스템에 제공됩니다.

Java로 스켈레톤 구현

시작을 위해 Java로 컴파일할 수 있는 스켈레톤 gRPC 서버를 제공합니다. 설치되었습니다 다음에서 확인하세요. 샘플 > gRPC 참조 구현 섹션으로 이동합니다. 이 서버는 지원하는 데 필요한 gRPC 메서드를 스텁 처리했습니다. 여기에는 인증 및 건강 관리 서비스가 포함됩니다

요구사항

gRPC 오류 및 비즈니스 로직 오류

파트너 백엔드가 gRPC 요청을 처리할 때 두 가지 유형의 오류가 발생할 수 있습니다. 잘못된 데이터로 인해 발생하는 예기치 않은 오류 비즈니스 로직 오류를 예약을 생성하거나 업데이트할 수 없음을 나타냅니다 (예약 참조). Failure)을 확인합니다. 예를 들어 요청된 시간대를 이용할 수 없는 경우입니다.

예상치 못한 오류가 발생하면 표준 gRPC 오류 코드입니다. 이러한 예에는 다음 항목이 포함되나 이에 국한되지 않습니다.

  • INVALID_ARGUMENT는 CheckAvailability 및 CreateLease와 같은 RPC에서 사용됩니다. 제공된 슬롯에 잘못된 정보가 포함된 경우 반환되어야 합니다.
  • NOT_FOUND는 CreateBooking 및 ListBookings와 같은 RPC에서 사용되며 제공된 식별자를 파트너가 알 수 없는 경우 반환됩니다.

표준 gRPC 오류 코드는 각 메서드의 참조를 확인하거나 전체 상태 코드 목록에 나열되어 있습니다.

오히려 비즈니스 로직 오류는 예약 Failure 반환됩니다. 생성 시 비즈니스 로직 오류가 발생할 수 있습니다. 리소스 업데이트(RPC CreateBooking 처리) 예약을 업데이트하는 중입니다. 이러한 예에는 다음 항목이 포함되나 이에 국한되지 않습니다.

  • SLOT_UNAVAILABLE은 요청된 슬롯을 더 이상 사용할 수 없는 경우에 사용됩니다.
  • 제공된 신용카드 유형이 다음과 같은 경우 PAYMENT_ERROR_CARD_TYPE_REJECTED가 사용됩니다. 허용되지 않습니다.

멱등성

네트워크를 통한 통신이 항상 신뢰할 수 있는 것은 아니며 Google Reserve는 응답이 수신되지 않으면 RPC를 재시도합니다. 따라서 변하는 모든 RPC는 상태 (CreateBooking, UpdateBooking)가 멱등적이어야 합니다. 요청 메시지 이러한 RPC에는 요청을 고유하게 식별하고 파트너가 재시도된 RPC( 단일 예약) 및 두 개의 개별 예약입니다.

이러한 예에는 다음 항목이 포함되나 이에 국한되지 않습니다.

  • 성공적인 CreateBooking RPC 생성된 예약이 포함되며 경우에 따라 결제가 예약 절차의 일부로 처리됩니다. 정확히 동일한 CreateBookingRequest 두 번째 수신 (idempotency_token 포함)이 수신되면 CreateBookingResponse가 반환되어야 합니다. 두 번째 예약이 생성되지 않으며 해당하는 경우 사용자에게 정확히 한 번 청구됩니다. CreateBooking 시도가 실패하면 파트너 백엔드에서 다시 시도해야 합니다. 동일한 요청이 다시 전송되면

멱등성 요구사항은 멱등성 토큰이 포함된 모든 메서드에 적용됩니다.

gRPC 서버 보안 및 인증

Actions Center에서 백엔드로의 호출은 SSL/TLS를 사용하여 보호되어야 합니다. 인증서 기반의 상호 클라이언트/서버 인증을 사용합니다. 이를 위해서는 gRPC 구현을 위한 유효한 서버 인증서를 사용하고 유효한 클라이언트 인증서입니다.

서버 인증서: 파트너 서버에 유효한 서버 인증서와 함께 인증서 (이 링크 참조)를 허용된 루트 CA 목록 참조). GRPC 서버 구현은 확인할 수 있습니다 이를 수행하는 가장 쉬운 방법은 중간 인증서를 PEM 형식으로 제공합니다. 서버 인증서 (PEM 형식)도 필요합니다.

연결 시 서버 인증서가 확인되고 자체 서명됨 인증서는 허용되지 않습니다. 실제 인증서 내용은 유효한 경우에만 광고가 게재됩니다. 인증서의 유효성을 확인할 수 있습니다. 다음 명령어를 사용합니다.

echo "" | openssl s_client  -connect YOUR_URL:YOUR_PORT  -showcerts -CApath /etc/ssl/certs

클라이언트 인증서: Google을 파트너에게 인증하기 위해 Google을 Google로 인증합니다. Google 인터넷 기관 G2 (CA)에서 발행한 클라이언트 인증서를 인증서)를 다음 속성이 포함됩니다.

필드
CN mapsbooking.businesslink-3.net
SAN DNS:mapsbooking.businesslink-3.net

이 클라이언트 인증서가 없는 연결 시도는 인증 기관에 의해 거부되어야 합니다. 있습니다.

클라이언트 인증서의 유효성을 검사하기 위해 서버는 신뢰할 수 있는 클라이언트 세트를 사용합니다. 루트 인증서를 사용합니다 이 신뢰할 수 있는 루트 집합을 클러스터에서 가져올 수 있습니다. Mozilla와 같은 기관 또는 현재 Google 인터넷에서 권장하는 루트 세트를 권한 G2. 둘 다 경우에 따라 루트 인증서를 수동으로 업데이트해야 할 수도 있습니다.

gRPC 상태 확인 프로토콜 구현

GRPC 상태 점검 구현 프로토콜 이 프로토콜을 사용하면 Google에서 gRPC의 백엔드 상태를 모니터링할 수 있습니다. 있습니다. 서비스 사양 GRPC 배포의 일부입니다. GRPC 명명 규칙에 따라 서비스의 상태 확인 호출에서 ext.maps.booking.partner.v2.BookingService(API v2의 경우) 또는 API v0의 경우 ext.maps.booking.partner.v0.BookingService 상태 점검은 다른 엔드포인트와 동일한 URL 및 PORT에서 실행됩니다.

다른 버전

다른 버전의 API에 관한 문서는 다음 페이지를 참조하세요. * API v3 * API v0