Esta página descreve como as aplicações do App Engine enviam pedidos HTTP e HTTPS e recebem respostas. Para ver exemplos de código que demonstram como emitir pedidos HTTP e HTTPS a partir da sua aplicação do App Engine, consulte o artigo Emitir pedidos HTTP(S).
Pedidos
No tempo de execução do Java 8 do App Engine, pode usar a classe abstratajava.net.URLConnection e as classes relacionadas da biblioteca padrão do Java para fazer
ligações HTTP e HTTPS a partir da sua aplicação Java.
Em alternativa, também pode usar a API URL Fetch do App Engine, que fornece uma implementação dos métodos definidos em URLConnection através da API URL Fetch. Para obter informações sobre a utilização das classes Java nativas em comparação com a API URL Fetch, consulte o artigo Vantagens da utilização de chamadas Java padrão e não do URL Fetch no Java 8.
Protocolos de pedidos
Uma aplicação pode obter um URL através de HTTP ou HTTPS. O protocolo que deve ser usado é inferido através da análise do protocolo no URL de destino.
O URL a obter pode usar qualquer número de porta nos seguintes intervalos:
80-90440-4501024-65535.
Se a porta não for mencionada no URL, a porta é implícita no protocolo. Os pedidos HTTP ocorrem na porta 80 e os pedidos HTTPS ocorrem na porta 443.
Métodos de pedido
Se emitir pedidos através da classe Javajava.net.URLConnection padrão, pode usar qualquer método HTTP suportado.
Se emitir pedidos através do serviço URL Fetch, pode usar qualquer um dos seguintes métodos HTTP:
GETPOSTPUTHEADDELETEPATCH
Um pedido pode incluir cabeçalhos HTTP e, para pedidos POST, PUT e PATCH, um payload.
Encaminhamento por proxy de pedidos
Tenha em atenção que o serviço URL Fetch usa um proxy compatível com HTTP/1.1 para obter o resultado.
Para impedir que uma aplicação cause uma recursão infinita de pedidos, um controlador de pedidos não pode obter o seu próprio URL. Ainda é possível causar uma recursão infinita por outros meios. Por isso, tenha cuidado se a sua aplicação puder ser feita para obter pedidos de URLs fornecidos pelo utilizador.
Cabeçalhos do pedido
A sua aplicação pode definir cabeçalhos HTTP para o pedido de saída.
Quando envia um pedido HTTP POST, se um cabeçalho Content-Type não for definido explicitamente, o cabeçalho é definido como x-www-form-urlencoded.
Este é o tipo de conteúdo usado pelos formulários Web.
Por motivos de segurança, não é possível modificar os seguintes cabeçalhos pela aplicação:
Content-LengthHostVaryViaX-Appengine-Inbound-AppidX-Forwarded-ForX-ProxyUser-IP
Estes cabeçalhos são definidos com valores precisos pelo App Engine, conforme
adequado. Por exemplo, o App Engine calcula o cabeçalho Content-Length a partir dos dados do pedido e adiciona-o ao pedido antes de o enviar.
Os seguintes cabeçalhos indicam o ID da aplicação da app requerente:
User-Agent. Este cabeçalho pode ser modificado, mas o App Engine anexa uma string de identificador para permitir que os servidores identifiquem os pedidos do App Engine. A string anexada tem o formato"AppEngine-Google; (+http://code.google.com/appengine; appid: APPID)", em queAPPIDé o identificador da sua app.X-Appengine-Inbound-Appid. Este cabeçalho não pode ser modificado e é adicionado automaticamente se o pedido for enviado através do serviço URL Fetch quando o parâmetro follow redirects estiver definido comoFalse.
Limites de tempo dos pedidos
Pode definir um prazo ou um tempo limite para um pedido. Por predefinição, o tempo limite de um pedido é de 10 segundos.
O prazo máximo é de 60 segundos para pedidos HTTP(S) e 60 segundos para pedidos de tarefas agendadas e filas de tarefas.
Quando usa a classe abstrata URLConnection com a obtenção de URLs, o serviço usa o limite de tempo de ligação (setConnectTimeout()) mais o limite de tempo de leitura (setReadTimeout()) como prazo.
Pode enviar pedidos síncronos e pedidos assíncronos. O seguinte comportamento aplica-se à API URL Fetch:
- Pedidos síncronos: a chamada de obtenção aguarda até que o anfitrião remoto devolva um resultado e, em seguida, devolve o controlo à aplicação. Se o tempo de espera máximo para a chamada de obtenção for excedido, a chamada gera uma exceção.
- Pedidos assíncronos: o serviço de obtenção de URL inicia o pedido e, em seguida, devolve imediatamente um objeto. A aplicação pode realizar outras tarefas enquanto o URL está a ser obtido. Quando a aplicação precisa dos resultados, chama um método no objeto, que aguarda a conclusão do pedido, se necessário, e, em seguida, devolve o resultado. Se existirem pedidos de obtenção de URLs pendentes quando o controlador de pedidos sair, o servidor de aplicações aguarda que todos os pedidos restantes sejam devolvidos ou atinjam o respetivo prazo antes de devolver uma resposta ao utilizador.
Ligações seguras e HTTPS
A sua aplicação pode obter um URL de forma segura através do HTTPS para estabelecer ligação a servidores seguros. Os dados de pedido e resposta são transmitidos através da rede de forma encriptada.
Por predefinição, o proxy URL Fetch valida o anfitrião com o qual contacta. Este comportamento permite à API detetar ataques man-in-the-middle entre o App Engine e o anfitrião remoto quando usa HTTPS.
Responses
Se usar a API URL Fetch, tenha em atenção que o serviço URL Fetch devolve todos os dados de resposta, incluindo a resposta, o código, os cabeçalhos e o corpo.
Por predefinição, se o serviço URL Fetch receber uma resposta com um código de redirecionamento, o serviço segue o redirecionamento. O serviço segue até cinco respostas de redirecionamento e, em seguida, devolve o recurso final. Pode dar instruções ao serviço URL Fetch para não seguir redirecionamentos e, em alternativa, devolver uma resposta de redirecionamento à aplicação.
Usar a obtenção de URLs no servidor de desenvolvimento
Quando a sua aplicação está em execução no servidor de desenvolvimento do App Engine no seu computador, as chamadas ao serviço URL Fetch são processadas localmente. O servidor de desenvolvimento obtém URLs contactando diretamente anfitriões remotos a partir do seu computador, usando qualquer configuração de rede que o computador esteja a usar para aceder à Internet.
Quando testar as funcionalidades da sua aplicação que obtêm URLs, certifique-se de que o seu computador consegue aceder aos anfitriões remotos.
Quotas e limites para a obtenção de URLs
Para o tempo de execução Java, pode usar a API Javajava.net.URLConnection padrão, em vez da URLFetch, onde estas considerações de quota e limite não se aplicam.
Para ver informações sobre as quotas do serviço de obtenção de URL, consulte o artigo Quotas. Para ver a utilização atual da quota da sua aplicação, aceda à página Detalhes da quota naGoogle Cloud consola.
Aceda à página Detalhes da quota
Além disso, aplicam-se os seguintes limites à utilização do serviço URL Fetch:
| Limite | Montante |
|---|---|
| Tamanho do pedido | 10 megabytes |
| Tamanho do cabeçalho do pedido | 16 KB (tenha em atenção que isto limita o comprimento máximo do URL que pode ser especificado no cabeçalho) |
| Tamanho da resposta | 32 megabytes |
| Prazo máximo (processador de pedidos) | 60 segundos |
| Prazo máximo (fila de tarefas e controlador de tarefas cron) | 60 segundos |
O que se segue?
Execute exemplos de código e receba orientações sobre como emitir pedidos a partir da sua aplicação em Emitir pedidos HTTP(S).