Práticas recomendadas

As práticas recomendadas a seguir se aplicam à integração completa das reservas da Central de ações e podem ser usadas para evitar problemas de usabilidade e desempenho. Dados de baixa qualidade podem levar à remoção do inventário.

Feeds

  • Se um serviço não tiver uma duração definida, defina duration_sec no feed de disponibilidade como uma das seguintes opções:
    • Número de segundos necessários para executar o serviço de maneira razoável.

    • O número médio de segundos necessários para concluir o serviço.

  • Faça com que a entrada do campo Category no feed do comerciante seja específica. Por exemplo, um restaurante pode enviar um tipo específico, como francês ou japonês. Para mais detalhes, consulte os possíveis valores de categoria em Tipos de lugar.

  • Defina os Termos de Serviço específicos do comerciante no campo Terms do feed do comerciante para que a observação a seguir apareça abaixo do botão Reservar:

    Ao continuar, você concorda com os Termos de Serviço de <merchant>
    . Nesse caso, "Termos de Serviço" é um link que, quando clicado, exibe o texto definido no campo terms.

  • Compacte seus feeds usando gzip

Servidor de agendamento

Para otimizar sua integração da API Maps Booking, faça o seguinte:

  • Sempre use carimbos de data/hora UNIX no formato UTC.
  • Gere um ID exclusivo quando um novo agendamento na API CreateBooking for chamado.

atualizações em tempo real;

Para garantir a melhor experiência do usuário durante o processo de reserva, faça o seguinte:

  • Para uma implementação padrão, use a API BookingNotifications para mudar o horário de início, a duração e o estado do agendamento, como cancelamento ou não comparecimento, de um horário.
  • Se você fizer qualquer mudança na reserva da Central de ações, sempre envie atualizações de reservas em tempo real com a API BookingNotification para que os dados não fiquem desatualizados no lado do Centro de ações. Por exemplo, é possível cancelar, reagendar ou atualizar um agendamento pelo sistema na Central de ações.
  • Para cada atualização de agendamento de UpdateBookingRequest, verifique se o valor UpdateBookingResponse contém o ID e se todos os campos atualizados precisam refletir o novo valor.
  • Se a RTU de inventário for implementada
    • Atualize a disponibilidade somente em lotes de 100 a 1.000 slots por chamada de API.
    • Use os campos *Restrict (como startTimeRestrict) para restringir o destino de edição, reduzir o tamanho do payload e evitar o envio de muitos dados inalterados.
    • Se você ativar várias linhas de execução, implemente uma espera exponencial para evitar erros de limitação. Se você não implementar uma espera exponencial corretamente, poderá receber um erro de cota RESOURCE_EXHAUSTED. É possível repetir a espera exponencial para lidar com eles, mas, se você perceber que o servidor costuma atingir cotas ao executar ReplaceServiceAvailability, configure o servidor para substituir em lote para disponibilidade. Essa solução evita erros de cota porque reduz o número de chamadas de API que seu servidor precisa fazer.
  • Defina os limites de tempo de resposta da chamada de API para menos de um segundo. Verifique se o servidor consegue processar cinco consultas por segundo (QPS) com latência inferior a um segundo em pelo menos 95% do tempo.