Lista de verificação de pré-lançamento

Onde gerenciar seu ID do cliente no Console do Google Cloud

O recurso de gerenciamento de ID do cliente do plano Premium está migrando do portal de suporte para o Console do Cloud na página "Credenciais" do Maps, na seção Contas de serviço.

A nova área "ID do cliente" na página "Credenciais"

Observação: o plano Premium da Plataforma Google Maps não está mais disponível para inscrições ou novos clientes.

Garantir que sua equipe tenha acesso aos recursos necessários

Manter a mensagem de boas-vindas ao plano Premium da Plataforma Google Maps em um lugar seguro

Por que é importante: sua mensagem de boas-vindas é o kit básico do plano Premium da Plataforma Google Maps e, talvez, também o kit de primeiros socorros. Ela contém informações importantes, como o ID do projeto do Console do Google Cloud, o ID do cliente e a chave criptográfica, necessárias para começar a usar o plano Premium. A mensagem também apresenta todos os dados necessários para entrar em contato com a equipe de suporte do plano Premium caso você enfrente algum problema técnico com as APIs Google Maps.

Usar o Console do Google Cloud

Por que é importante: o Console do Google Cloud dá acesso a informações como relatórios de uso, feeds de notícias e recursos para desenvolvedores. E o mais importante é que ele permite registrar casos de suporte com a equipe dedicada do plano Premium caso você tenha algum problema técnico durante o desenvolvimento ou o lançamento.

Antes do lançamento, ative o acesso ao Console do Cloud para todos os desenvolvedores responsáveis pela manutenção do seu aplicativo. Se ocorrer algum problema técnico, o acesso ao Console do Cloud permitirá que os membros da sua equipe entrem em contato com o suporte e que nossa equipe de suporte fale com as partes interessadas na organização. Por exemplo, talvez a equipe de suporte precise falar com a organização se detectar tráfego ou comportamento anormal que possa causar falhas no seu aplicativo. Se tivermos o contato dos desenvolvedores, poderemos evitar interrupções inesperadas.

Inscrever-se em grupos de e-mail de notificação

Por que é importante: para garantir que você fique por dentro dos desenvolvimentos e mudanças das APIs Maps, recomendamos se inscrever em um ou mais dos seguintes grupos de e-mail:

  • google-maps-platform-notifications: atualizações técnicas sobre APIs e serviços da Web da Plataforma Google Maps, notificações sobre falhas temporárias e anúncios de recursos da plataforma (de três a cinco mensagens por mês)
  • google-maps-js-api-v3-notify: lançamentos da API Google Maps JavaScript (cerca de quatro mensagens por ano)

Inscrever-se nos feeds de notificação relevantes

Por que é importante: para garantir que você fique por dentro dos desenvolvimentos e mudanças das APIs Maps, recomendamos se inscrever nos feeds de notificação relevantes, conforme descrito na seção de Perguntas frequentes.

Você também pode assinar este feed RSS sobre Anúncios da API Google Maps Premier: falhas temporárias, atualizações, notificações de serviço:

http://google.force.com/services/xml/MapsRSS

Ter a linha direta de suporte à mão

1-877-355-5787 para clientes dos EUA, +1 404-978-9282 para clientes fora dos EUA.

Por que é importante: a linha direta é sua maneira de usar o suporte por telefone. Os números e o PIN de cada país estão disponíveis no Console do Cloud. Você pode usar a linha direta de suporte para informar problemas técnicos à nossa equipe, mas esse recurso é destinado apenas a casos de interrupção de produção ou serviços inutilizáveis. Nossos níveis de prioridade são definidos neste documento.

Otimizar o aplicativo

Configurar um firewall para permitir acesso aos serviços da Plataforma Google Maps

Por que é importante: os serviços da Plataforma Google Maps usam vários domínios, sendo que alguns não pertencem ao endereço *google.com. Se você usa um firewall restritivo, é importante permitir acesso aos domínios usados pelos serviços da API Maps. Se o firewall não permitir acesso a esses domínios, as solicitações de API falharão, o que poderá causar erro nos aplicativos. Veja uma lista completa dos domínios usados pelas APIs Maps.

Não recomendamos gerenciar as restrições de firewall por endereço IP, porque os IPs associados a esses domínios não são estáticos.

Observação: os serviços da Plataforma Google Maps usam a porta 80 (HTTP) e 443 (HTTP) para tráfego de entrada e saída. Esses serviços também exigem solicitações GET, POST, PUT, DELETE e HEAD. Configure o firewall para permitir tráfego por essas portas e solicitações de acordo com a API e o caso de uso.

Carregar as APIs usando o nome do host SSL correto

Por que é importante: os aplicativos que carregam as APIs Maps por SSL devem fazer isso usando https://maps.googleapis.com em vez do nome do host legado https://maps-api-ssl.google.com.

Autorizar seus domínios SSL para uso com a API Maps JavaScript

Por que é importante: ao usar a API Maps JavaScript com um domínio SSL, é essencial que você tenha autorizado explicitamente seus domínios HTTPS para garantir que as solicitações não sejam recusadas. Ao autorizar http://yourdomain.com, o SSL equivalente (https://yourdomain.com) não é automaticamente ativado. Verifique sua lista de domínios autorizados no Console do Cloud rolando para baixo até a seção ID do cliente. Para resolver problemas relacionados ao uso de APIs do lado do cliente com um domínio SSL, verifique se todos os elementos da página são carregados usando HTTP. Consulte o guia para resolver problemas de autorização.

Selecionar a versão correta da API

Por que é importante: antes de desenvolver seu aplicativo, é importante saber quais versões das APIs estão obsoletas. Ao optar por desenvolver usando versões não obsoletas de APIs, você terá um tempo de desenvolvimento e um custo menores quando as versões obsoletas se tornarem indisponíveis.

Especificamente, é essencial compreender o esquema de controle de versões usado pela API Maps JavaScript para evitar o uso acidental de uma versão incorreta da API no seu ambiente.

Por exemplo, o uso de uma versão experimental da API no ambiente de desenvolvimento ou teste pode ser aceitável, mas é altamente desaconselhável usar essas versões em um ambiente de produção. Nosso SLA se aplica apenas a versões estáveis da API. Portanto, use somente essas versões no ambiente de produção.

Consulte o guia sobre versões da API Maps JavaScript.

Escolher entre projeto do lado do cliente e do servidor

Por que é importante: a escolha por uma abordagem no lado do cliente ou do servidor é uma decisão de arquitetura e é absolutamente fundamental para a estabilidade e a escalabilidade do seu aplicativo. De modo geral, a abordagem do lado do servidor deve ser usada para processamento off-line prévio e posterior de registros (ou seja, fora do aplicativo). Como alternativa, a abordagem do lado do cliente deve ser usada nas partes dos aplicativos que interagem com os usuários (ou seja, que processam solicitações enviadas pelos usuários em tempo real).

Implantar a abordagem do lado do servidor nos pontos onde ela deveria ser do lado do cliente é o principal motivo do esgotamento de cotas e, portanto, de erros nos aplicativos. É altamente recomendado consultar as estratégias de geocodificação antes de projetar ou lançar aplicativos que dependam de chamadas do lado do servidor.

Otimizar o uso de cotas

Por que é importante: entender como seu aplicativo consome a cota, conhecida como créditos de APIs Maps, ajuda a reduzir o valor pago. Por exemplo, se você estiver usando a API Maps JavaScript, o aplicativo consumirá créditos de APIs Maps em cada carregamento de mapa. Consulte o guia sobre taxas e limites de uso do plano Premium.

Gerenciar o uso de cotas de serviços da Web

Por que é importante: por padrão, a cota de serviços da Web compartilhada é definida como 100.000 solicitações diárias gratuitas. Para mais detalhes sobre a cota por API, consulte a documentação de limites de uso. Verifique suas cotas no Console do Cloud ou registre uma consulta ao suporte se você tiver problemas de cota.

Antes de lançar o serviço, é fundamental entender os diferentes erros relacionados a cotas (por exemplo: OVER_QUERY_LIMIT, User Rate Limit Exceeded) e configurar a lógica adequada no aplicativo para poder responder a esses erros quando exceder a cota. Comece lendo as perguntas frequentes sobre limites de uso. Para mais informações sobre os códigos de status retornados pelas APIs individuais, consulte o Guia do desenvolvedor dessa API. Por exemplo, consulte o guia sobre códigos de status da API Directions. Entender e implementar esses conceitos reduzirá consideravelmente a probabilidade do aplicativo exceder a cota permitida, ser bloqueado pelo Google e/ou apresentar erros.

Executar testes de carga no seu app

Por que é importante: use o teste de carga do aplicativo para garantir que ele consiga lidar com altos volumes de solicitações sem exceder as cotas das APIs Maps.

Os testes de carga em tempo real usando os Serviços do Google farão com que o aplicativo exceda a cota permitida e seja bloqueado pelo Google. A Plataforma Google Maps pode exibir volumes muito altos. Em 2012, o Siga o Papai Noel atendeu a 1.600.000 solicitações por segundo. Portanto, é desnecessário executar testes de carga com os Serviços do Google. Em vez disso, faça testes de carga com seu aplicativo para garantir que ele consiga lidar com altos volumes de solicitações sem exceder as cotas das APIs Maps. Exemplo: se sua cota para a API Geocoding for de 20 QPS (consultas por segundo), o teste de carga do aplicativo deverá garantir que ele consiga processar 600 QPS sem enviar mais de 20 QPS para a API Geocoding.

Para fazer isso com segurança, os testes precisam ser executados em uma API simulada (falsa), um serviço que possa absorver grandes quantidades de solicitações e respondê-las com respostas válidas, sem envolver a Plataforma Google Maps. Assim, você testa a carga do aplicativo sem correr o risco de bloqueio pela Plataforma Google Maps.

Consulte este exemplo de uma API simulada, implementada como um pequeno aplicativo Google App Engine. Você pode fazer o upload desse exemplo para seu próprio aplicativo App Engine (depois de registrar um em appengine.google.com) e configurar o aplicativo para enviar solicitações nele em vez de para maps.googleapis.com.

As cotas padrão (gratuitas) do App Engine geralmente são suficientes para os testes de carga, muito além das cotas dos serviços da Web das APIs Maps. Verifique se o aplicativo define o cabeçalho User-Agent correto para ativar a compactação de respostas. Isso é essencial para garantir o uso eficiente da largura de banda, o que é importante principalmente para um aplicativo App Engine que atende a um alto volume de respostas em texto simples (JSON/XML). Se precisar de uma cota maior para o aplicativo App Engine, você também poderá ativar o faturamento. No entanto, raramente isso será necessário.

Migrar seu aplicativo de uma licença padrão para Premium

Incluir um ID do cliente ou chave de API em solicitações de API

Por que é importante: uma das coisas mais importantes que você pode fazer pelo seu aplicativo é incluir o ID do cliente (gme-yourclientid) ou a chave de API (que tem esta aparência: AIzaSyBdVl-cTICSwYKrZ95SuvNw7dbMuDt1KG0) nas suas solicitações de API. O ID do cliente ou a chave de API identifica suas solicitações como sendo do plano Premium da Plataforma Google Maps.

É necessário incluir esses identificadores nos seus aplicativos para aproveitar os recursos específicos do plano Premium, bem como para receber suporte técnico e garantir que o aplicativo seja coberto pelo nosso SLA.

Para a maioria das APIs, você pode usar um ID do cliente ou uma chave de API. O ID do cliente é informado na mensagem de boas-vindas enviada ao contato principal da sua empresa. Você também pode gerar a própria chave de API no Console do Google Cloud.

Os detalhes estão no guia sobre autenticação e autorização.

Incluir a chave de API ou o ID do cliente (mas não ambos) nas solicitações de API

Por que é importante: para carregar corretamente a API Maps JavaScript ou enviar uma solicitação a outras APIs Google Maps, você precisa incluir ou o ID de cliente, ou a chave de API, mas não os dois. Se você usar um ID do cliente, terá que remover qualquer parâmetro key. Caso sua solicitação inclua um ID do cliente e uma chave, o aplicativo poderá apresentar comportamentos ou erros inesperados.

Consulte o guia de autenticação e autorização para ver informações completas sobre como formatar corretamente as solicitações do plano Premium por API.

Ao utilizar um ID do cliente, autorizar os domínios para uso com a API Maps JavaScript

Por que é importante: para impedir que sites não autorizados usem seu ID de cliente, a API Maps JavaScript exige que você autorize todos os domínios dos sites que usarão o ID junto à nossa equipe de suporte. Não é necessário registrar um URL para usar uma chave de API em vez de um ID do cliente. Se um site que tentar usar seu ID do cliente não corresponder aos URLs autorizados para esse ID, ele não conseguirá utilizar a API. Você pode autorizar domínios a qualquer momento. Portanto, confirme se os domínios de todos os seus sites foram autorizados antes do lançamento.

Para verificar sua lista de domínios autorizados no Console do Cloud, acesse a página Credenciais e role até a seção ID do cliente.

No caso de problemas de autorização, confira o guia de solução de problemas de autorização antes de registrar uma consulta.

Ao utilizar um ID do cliente, assinar solicitações de serviço da Web usando uma assinatura gerada com sua chave criptográfica privada

Por que é importante: sua chave criptográfica privada é usada para gerar assinaturas digitais que informam ao Google que as solicitações vêm de uma fonte confiável. Nossas APIs de serviços da Web exigem que você adicione uma assinatura digital às suas solicitações, caso utilize um ID do cliente para autenticação. Isso adiciona uma camada de segurança à solicitação, protegendo melhor a cota associada ao seu ID do cliente. A chave criptográfica (por exemplo, vNIXE0xscrmjlyV-12Nj_BvUPaw=) está incluída na mensagem de boas-vindas enviada aos contatos principais da sua organização.

Observação: a chave criptográfica é usada para gerar assinaturas. Não a anexe às solicitações como a própria assinatura. A chave criptográfica é semelhante a uma senha de cartão. Ela é usada como autenticação para acessar sua conta e nunca deve ser compartilhada abertamente ou ficar visível para fontes não confiáveis. As solicitações de serviços da Web do plano Premium que não estiverem devidamente assinadas serão rejeitadas pelos nossos servidores. Por isso, é fundamental que seu aplicativo assine corretamente a solicitação antes do lançamento. Consulte o guia sobre autenticação e autorização.

Rastrear o uso de aplicativos

Por que é importante: como cliente do Plano Premium, você tem acesso a relatórios detalhados sobre o uso do aplicativo, incluindo solicitações feitas, créditos consumidos, erros retornados e muito mais. Consulte o guia sobre relatórios.

Um parâmetro channel é opcional e permite rastrear o uso do ID do cliente atribuindo um canal distinto a cada um dos aplicativos. Os parâmetros de canal não precisam ser registrados no ID do cliente. Basta adicionar o parâmetro de canal à solicitação de API, e os resultados de uso por canal serão exibidos nos relatórios do portal de suporte dentro de um a dois dias após a implementação. Você decide onde implementar os canais e, portanto, como o uso é agregado. Antes do lançamento, decida se o aplicativo deve integrar parâmetros de canal para rastrear o uso do aplicativo.

O parâmetro channel precisa ter o seguinte formato:

  • Precisa ser uma string ASCII alfanumérica.
  • É permitido usar os caracteres ponto (.), sublinhado (_) e hífen (-).
  • O parâmetro channel é indiferente a maiúsculas. Os parâmetros channel em maiúsculas e em maiúsculas e minúsculas são mesclados no equivalente em minúsculas. Por exemplo, o uso no canal CUSTOMER é combinado ao uso no canal customer.

É possível implementar até 2.000 canais distintos por ID do cliente.

Para usar o parâmetro channel, inclua-o no URL da solicitação com o parâmetro client usado para transmitir o ID do cliente.

O parâmetro de canal precisa ser um valor atribuído estaticamente para cada aplicativo. Ele não pode ser gerado dinamicamente e usado para rastrear usuários individuais.