Implementação e configuração
Ofereça mais que pontos ou milhas a viajantes
Com o modelo sem marca, viajantes podem juntar uma moeda de fidelidade (conforme definida pelo seu programa) e resgatar as recompensas em compras de viagens. Este documento apresenta uma visão geral das operações de fidelidade disponíveis e explica o processo para você implementar os serviços nos ambientes de teste e produção.
Você vai oferecer serviços RESTFul padrão com conteúdo JSON. É recomendável usar tokens de acesso e JSON Web Tokens para cada solicitação da API. Há instruções de segurança adicionais para chamar as APIs, e todos os elementos de dados sensíveis no conteúdo de solicitação e resposta serão criptografados.
Na hora de configurar o modelo de site, você pode optar por permitir que clientes resgatem os pontos de fidelidade, seja qual for a linha de negócios que você tenha selecionado.
Os consumidores também podem entrar em contato com agentes do site da marca Expedia para usar esses pontos. Os nossos agentes internos vão usar a API de informações da conta para verificar os dados do viajante. Após essa análise, vão usar a API de banco de pontos para consultar o saldo da conta do viajante e auxiliar na reserva.
O seu gestor de lançamento da Expedia vai trabalhar com você para obter todas as informações necessárias, incluindo a configuração do SSO, como: o nome da sua marca ou do seu programa, os níveis de associado ou segmentos do seu programa, o nome da sua moeda de fidelidade e a proporção do resgate (por exemplo, R$ 1 gasto = 100 pontos).
Também vamos precisar destes dados:
- API de token de acesso
- ClientId e segredo
- Pontos de extremidade do resgate de fidelidade
- O acordo de nível de serviço (SLA) que você comunicou aos clientes
Para a configuração do seu lado, vamos informar:
- Uma especificação OpenAPI
- Ponto de extremidade de JSON Web Key (JWK), se você estiver usando o parâmetro Authorization2
Fazer chamadas de API
A Expedia usa o token de acesso para invocar a API. O token de acesso é informado no cabeçalho HTTP de autorização como um token Bearer. O sistema vai gerar o token de assinatura da solicitação necessário e o informar no cabeçalho HTTP Authorization2.
Ponto de extremidade de autorização
Se quiser obter um token de acesso para chamadas de API, primeiro você deve configurar um servidor de autorização com um ID de cliente e um segredo. Depois, você vai usar uma chamada POST : https://<your-oauth-endpoint> para fazer a solicitação.
Solicitação
| Campo | Descrição | Exemplo do valor | Tipo de campo | Obrigatório? |
|---|---|---|---|---|
content-type | Indica o formato da solicitação. | application/x-www-form-urlencoded | Sequência | Sim |
grant_type | Método de autorização da solicitação, como as credenciais do cliente. | client-credentials&client_id=<client_id>&client_secret=<client_secret> | Sequência | Sim |
client_id | O identificador do aplicativo, conforme registrado. | a17c21ed& | Sim | |
client_secret | Segredo correspondente a client_id. | Sim |
Resposta
| Campo | Descrição | Exemplo do valor | Tipo de campo | Obrigatório? |
|---|---|---|---|---|
content-type | Indica o formato do corpo da resposta. | application/json | Sequência | Sim |
token_type | O público do token. Indica o tipo de acesso a ser concedido. | bearer | Sim | |
access_token | Um token de acesso que faz referência a client_id. | Sim | ||
expires_in | O tempo de expiração do token de acesso em segundos. | 86400 | Sim |
Erros
| Campo | Descrição | Exemplo do valor | Tipo de campo | Obrigatório? |
|---|---|---|---|---|
error | Ocorreu um erro. Por exemplo, um parâmetro inválido. | invalid_request invalid_client invalid_grant | Sequência | Sim |
errorMessage | Mensagem de erro personalizada usada para auxiliar no registro e na investigação de problemas. | Sequência | Sim |
Resposta do ponto de extremidade JWK
Vamos compartilhar um URL onde você pode buscar JWKs para usar na verificação. Por exemplo: GET : https:// <WLT_Domain>/keys/public-keys --header Authorization : Bearer - Partner_client_api_key
| Campo | Descrição |
|---|---|
alg | Algoritmo de assinatura. |
kty | Tipo de chave criptográfica. |
kid | Identificador da chave. |
use | Como a chave deve ser usada: para assinatura (sig) ou criptografia (enc). |
x5t | Impressão digital do certificado X.509. |
x5c | Cadeia do certificado X.509. |
expires_on | Data de validade do certificado. |
Assinatura da solicitação
Recomendamos que todas as solicitações de API sejam assinadas usando um JSON Web Token (JWT). Para assinar solicitações:
- Vamos configurar uma chave privada RSA de 2048 bits assinada por CA.
- Vamos publicar o certificado público por meio de um URL JWK (conforme mencionado acima).
- Em seguida, vamos criar um token JWT com reivindicações de emissor, assunto, público e expiração, bem como assinar o token usando a chave privada.
- O token JWT da Expedia vai ter os identificadores de chave kid e x5t, que contêm a impressão digital do certificado de chave pública.
- Ao realizar uma chamada de API, você vai extrair o JWT dos cabeçalhos de autorização e validar a assinatura do JWT usando a chave pública da Expedia. Você vai identificar a chave (caso várias chaves estejam presentes no URL JWK da Expedia) por meio do cabeçalho kid.
- Em seguida, vai agendar uma chamada de API para o ponto de extremidade JWK da Expedia para buscar o certificado de chave pública.
- Você também vai precisar usar a lógica de repetição para buscar um novo certificado se a validação da assinatura falhar.