Etapa 3: implementar o servidor de agendamento de listas de espera

Você precisa configurar um servidor de reserva para permitir que o Actions Center faça callbacks para criar e atualizar reservas em seu nome.

• A implementação das listas de espera de reservas. usada quando você participa do programa-piloto de listas de espera de reservas. Isso permite que a Central de ações extraia estimativas de espera e crie entradas na lista de espera em nome do usuário.
• A implementação padrão. Isso permite que o Centro de ações crie compromissos, agendamentos e reservas com você em nome do usuário. Para implementar um servidor de agendamento para a integração completa de reservas, consulte Implementar o servidor de agendamento.

Consulte a documentação do Portal do Google Cloud Partner Advantage para saber como configurar a conexão com seus servidores de agendamento do sandbox e de produção.

Implementar uma interface da API REST

Implemente uma interface de API com base em REST. Assim, o Google poderá enviar solicitações do servidor de agendamento por HTTP.

Para começar, configure um servidor de agendamento do sandbox ou de desenvolvimento que possa ser conectado ao ambiente do sandbox da Central de ações. Só mude para um ambiente de produção depois que o servidor do sandbox for completamente testado.

Métodos

Para cada tipo de servidor de agendamento, é necessário usar um conjunto diferente de métodos de API. Você pode fazer o download da definição do serviço no formato proto para começar a implementar a API. As tabelas a seguir mostram os métodos de cada implementação e incluem links para os formatos proto do serviço.

Implementação da lista de espera
Definição do serviço de lista de espera. Faça o download do arquivo de definição do serviço proto.

Método	Solicitação HTTP
HealthCheck	GET /v3/HealthCheck/
BatchGetWaitEstimates	POST /v3/BatchGetWaitEstimates/
CreateWaitlistEntry	POST /v3/CreateWaitlistEntry/
GetWaitlistEntry	POST /v3/GetWaitlistEntry/
DeleteWaitlistEntry	POST /v3/DeleteWaitlistEntry/

Recursos de API

Lista de espera

Estes recursos são usados para implementar o agendamento por lista de espera:

• WaitEstimate: uma estimativa de espera para um grupo (com base no tamanho dele) e comerciante específicos.
• WaitlistEntry: uma entrada do usuário na lista de espera.

Fluxo: criar uma entrada da lista de espera

Esta seção aborda como criar um agendamento para a integração de listas de espera de reservas.

Figura 2: fluxo de trabalho para criar uma entrada da lista de espera

Quando o usuário cria uma entrada da lista de espera, o Google envia o nome, sobrenome, número de telefone e e-mail dele. O e-mail é o mesmo da Conta do Google do usuário e é considerado um identificador exclusivo. Do seu ponto de vista, essa lista de espera precisa ser tratada como uma compra sem login, porque o Reservar com o Google não consegue procurar a conta do usuário no seu sistema. Verifique se a entrada final da lista de espera é idêntica às entradas dos comerciantes feitas no seu sistema.

Segurança e autenticação

Toda a comunicação com seu servidor de agendamento acontece por HTTPS. Portanto, é essencial que ele tenha um certificado TLS válido que corresponda ao nome DNS. Para ajudar a configurar o servidor, recomendamos o uso de uma ferramenta de verificação SSL/TLS disponível sem custo financeiro, como o SSL Server Test da Qualys.

Todas as solicitações que o Google fizer nesse servidor serão confirmadas pela autenticação básica de HTTP. As credenciais básicas de autenticação (nome de usuário e senha) do seu servidor de agendamento podem ser inseridas na página de configuração do servidor de agendamento no Portal do Google Partners. É preciso mudar de senha a cada seis meses.

Observação:é necessário definir o nome de usuário e a senha para sandbox e produção separadamente usando o comutador de ambiente.

Exemplos de implementações da estrutura

Para começar, confira os seguintes exemplos de estrutura de um servidor de agendamento escritos para frameworks Node.js e Java:

• Esqueleto do Node.js js-maps-booking-rest-server-v3-skeleton
• Esqueleto Java java-maps-booking-rest-server-v3-skeleton

Esses servidores usam os métodos REST em testes.

Observação:para a integração de listas de espera de reservas, mude os métodos REST para os métodos de listas de espera de reservas necessários.

Requisitos

Erros HTTP e de lógica de negócios

Quando seu back-end gerencia solicitações HTTP, podem ocorrer dois tipos de erro.

• Erros relacionados à infraestrutura ou dados incorretos
  • Informe esses erros ao cliente com códigos de erro HTTP padrão. Consulte a lista completa de códigos de status HTTP.
• Erros relacionados à lógica de negócios
  • Retorne o código de status HTTP definido como 200 OK e especifique a falha da lógica de negócios no corpo da resposta. Os tipos de erros de lógica de negócios variam de acordo com o tipo de implementação do servidor.

Para a integração de listas de espera de reservas, os erros de lógica de negócios são capturados em Falhas de lógica de negócios na lista de espera e retornados na resposta HTTP. Esses erros podem acontecer quando um recurso é criado. Por exemplo, ao gerenciar o método CreateWaitlistEntry. Os exemplos incluem, entre outros:

• ABOVE_MAX_PARTY_SIZE é usado quando a entrada da lista de espera solicitada excede o tamanho máximo de grupo permitido pelo comerciante.
• MERCHANT_CLOSED é usado quando a lista de espera não está aberta porque o comerciante já está fechado.

Idempotência

A comunicação pela rede nem sempre é confiável, e o Google poderá repetir solicitações HTTP se nenhuma resposta for recebida. Por isso, todos os métodos que modificam o estado precisam ser idempotentes:

• CreateWaitlistEntry
• DeleteWaitlistEntry

Para cada mensagem de solicitação, exceto DeleteWaitlistEntry, os tokens de idempotência são incluídos para identificar a solicitação de maneira exclusiva. Isso permite distinguir entre uma chamada REST repetida, com a intenção de criar apenas uma solicitação, e duas solicitações separadas. DeleteWaitlistEntry é identificado de forma exclusiva pelos IDs de entrada da lista de espera. Portanto, nenhum token de idempotência é incluído nas solicitações.

Veja a seguir alguns exemplos de como os servidores de agendamento lidam com a idempotência:

• Uma resposta HTTP CreateWaitlistEntry bem-sucedida inclui o ID da entrada de lista de espera criada. Se o mesmo CreateWaitlistEntryRequest for recebido uma segunda vez (com o mesmo idempotency_token), o mesmo CreateWaitlistEntryResponse precisará ser retornado. A segunda entrada não será criada, e nenhum erro será retornado.

  Se uma tentativa CreateWaitlistEntry falhar e a mesma solicitação for reenviada, o back-end vai tentar novamente.

O requisito de idempotência se aplica a todos os métodos que modificam o estado.