일반적인 API 흐름

다음 다이어그램은 클래스 삽입, 객체 저장 및 업데이트에 사용되는 일반적인 통신 흐름을 보여줍니다. 서버, 웹브라우저, Google Pay API for Passes 간에 이루어지는 모든 작업을 구현할 책임은 개발자에게 있습니다. 다음 다이어그램에서는 포인트를 예시로 들고 있지만 다른 모든 패스도 유사한 흐름을 사용합니다.

그림 1. API 흐름 다이어그램

JS 버튼 및 JWT 웹 링크의 일반적인 API 흐름

다음 개요는 그림 1과 동일한 프로세스를 자세히 설명합니다. 자바스크립트(JS) 버튼과 JSON 웹 토큰(JWT)의 일반적인 API 흐름이 나와 있습니다.

1. 포인트 카드 발급기관이 LoyaltyClass를 만듭니다.
1. 서버가 LoyaltyClass를 정의합니다.
2. 서버가 Google Pay API for Passes 서버에 LoyaltyClass를 삽입하는 POST 요청을 만듭니다.
참고: JS 버튼을 사용하는 경우 이 단계가 항상 적용되지는 않습니다. 글자 수 제한이 없으므로 클래스를 미리 삽입할 필요가 없습니다. 그러나 여러 번 사용할 수 있도록 클래스를 미리 삽입하는 것이 좋습니다. 주로 포인트 카드를 처리할 때 가장 효과적인 방법입니다.
2. 서버에는 특정 LoyaltyClass의 LoyaltyObject에 대한 JWT를 생성하는 서비스가 있습니다. 이 객체는 해당 사용자의 포인트 카드를 나타냅니다.
1. 서버에서 JWT를 사용하여 Google Pay에 저장(S2GP) 버튼을 렌더링합니다.
• 웹사이트의 경우 자바스크립트 버튼을 사용하세요.
• 이메일, SMS, 네이티브 앱의 경우 S2GP 버튼이 있는 JWT 링크를 사용하세요.
3. 사용자가 포인트 카드 발급기관의 웹사이트, 이메일, 네이티브 앱, SMS에서 Google Pay에 저장을 클릭하거나 탭합니다.
1. 사용자가 방문 페이지로 이동하여 LoyaltyClass 객체를 저장합니다. 저장할 객체는 JWT를 기반으로 방문 페이지에 렌더링됩니다. 네이티브 앱에서 버튼을 탭하면 Google Pay 앱에 객체를 저장하라는 메시지가 표시됩니다.
2. 사용자가 발급기관의 속성에서 Google Pay에 저장을 클릭하여 LoyaltyObject를 저장합니다.
3. LoyaltyObject가 Google 서버에 삽입된 다음 Google Pay 앱으로 푸시됩니다. LoyaltyObject는 '포인트 패스'라고도 합니다.
참고: 사용자의 저장 작업 또는 서버 REST가 LoyaltyClass 또는 LoyaltyObject를 처음으로 삽입한 후에는 동일한 classID 또는 objectID를 가진 후속 JWT가 이미 Google Server에 삽입된 항목을 렌더링합니다. JWT에서 기존 classID 또는 objectID의 정보를 변경해도 정보가 업데이트되지 않습니다. 기존 클래스 및 객체를 업데이트하는 방법은 4단계를 참조하세요.
4. 카드 발급기관이 카드 데이터를 업데이트합니다.
1. 포인트 카드 발급기관에서 Object.id를 사용하여 LoyaltyObject의 GET 요청을 합니다.
2. 포인트 카드 발급기관에서 LoyaltyObject를 업데이트합니다.
3. 포인트 카드 발급기관은 업데이트된 LoyaltyObject가 Google Pay API for Passes 서버에 삽입되도록 PUT 또는 PATCH 요청을 합니다.
4. LoyaltyObject가 Google Pay 앱으로 푸시됩니다.

'스키니' JWT 변형

브라우저에서 잘리기 때문에 웹 링크에 사용되는 JWT는 1,800자를 넘으면 안 됩니다. 이 같은 제한이 문제가 된다면 미리 클래스와 객체를 모두 삽입하는 것이 좋습니다. 그러면 JWT에서는 객체 ID 필드만 포함하면 됩니다.

참고: 사용자가 Google Pay에 패스를 저장하려는 경우에만 클래스와 객체를 삽입합니다. 스키니 JWT 저장 흐름을 시작하려면 저장 링크를 직접 정의하는 것이 좋습니다.

다음 다이어그램은 이메일 또는 SMS에 'Google Pay에 저장' 버튼을 추가하는 API 흐름을 보여줍니다.

그림 2. 스키니 JWT 다이어그램

JWT POST 요청 API 흐름

객체가 저장되기 전에 클래스를 만들고 삽입하는 데 필요한 백엔드 작업을 구현하기 어려울 때가 많지만 JWT에서 1,800자 제한을 초과할 가능성이 있습니다. 시간이 지나면서 많은 클래스가 생성되는 이벤트 티켓과 탑승권에 가장 효과적입니다.

참고: JWT POST 요청 메서드는 앱에서 저장할 때 사용할 수 있지만 POST 호출을 사용하기 때문에 SMS 또는 이메일에서는 사용할 수 없습니다.

항공편 클래스를 사용한 흐름의 예시는 다음과 같습니다.

1. 서버가 FlightObject 및 FlightClass 모두에 대한 JWT를 생성합니다. 둘 다 JSON으로 정의되며 FlightObject는 FlightClass를 참조합니다.
2. 이 JWT는 서버에서 클라이언트 애플리케이션으로 전송되어 Google Pay에 저장 버튼을 표시합니다. S2GP 브랜드 가이드라인을 따르는 버튼을 사용해야 합니다.
3. 사용자가 클라이언트 애플리케이션에서 S2GP 버튼을 클릭합니다.
   1. POST 요청이 JWT 엔드포인트로 전송됩니다. 그러면 클래스 ID와 객체 ID가 삽입됩니다. JWT의 클래스 ID 또는 객체 ID가 이미 시스템에 존재하는 경우 다시 삽입되지 않습니다. 기존 클래스 및 객체를 업데이트하는 방법은 API 참조 문서를 확인하세요. 이미 삽입된 상태여도 오류가 발생하지 않습니다.
   2. 반환된 URI 응답이 열려 사용자가 패스를 저장할 수 있습니다. 이 URI는 반환 후 일주일간 유효합니다.

API를 구현하려면 JWT POST 요청 메서드 사용을 참조하세요.

그림 3. JWT POST 요청 다이어그램

그림 3의 저장 흐름에서 '개발자 서버'와 'Google 서버' 사이에 화살표가 없습니다. 이는 JWT POST와 JWT 링크 및 인텐트 메서드의 기본적인 차이점입니다. 하지만 패스를 업데이트하려면 서버 간 통신을 구현하는 것이 좋습니다.