Por que não devo redirecionar as chamadas de http para https no contexto de APIs?

Introdução

É muito comum haver questionamentos como garantir que as chamadas direcionadas ao API plataform sejam feitas somente utilizando https. Uma das soluções, aparentemente mais óbvias para isso é redirecionar a request, forçando a nova URL usando https (retornando o status code 301 ou 302) para o consumidor. Essa estratégia funciona muito bem com web browsers, mas pode ser extramamente perigosa para outros tipos de consumidores

Por que não redirecionar?

Diferentemente de browsers, muitos API clients não estão configurados para executar follow em status code de redirect. Isso quer dizer que, fazer esse redirecionamento, tem potencial para gerar indisponibilidade em diversas APIs (dependendo do client utilizado para consumi-la). Mesmo quando estão configurados para executar o follow, muitos clientes convertem POST para GET (padrão) no redirecionamento. A RFC 2616 ¹ explica esse comportamento incorreto. Essa configuração, embora altamente não recomendada, pode ser feita por meio de interceptor, pois há possibilidade de aplicar o redirect com granularidade.

Como devo proceder para que todas as requests efetuadas ao meu ambiente sejam via https?

Se o objetivo final é migrar para que todos usam https, a sugestão é:

1. Criar um dashboard e acompanhar as requests que chegam via http (por meio de custom search no headerx-forwarded-proto
2. Acompanhar esse dashoard e orientar os consumidores/integradores a fazer a alteração da URL client-side. Esse pode ser um processo longo, mas é o único capaz de assegurar um enforcement seguro.
3. Após um limiar aceitável (ex: 90% das chamadas já são via https), fazer o bloqueio de requests http via interceptor (para que continuem tendo a visibilidade de consumidores usando http).
4. Acompanhar as requests vindouras que continuam em http e seguir no caminho de orientação.

Referências

1 - https://tools.ietf.org/html/rfc2616#section-10.3.2