Ao executar uma API, se eu corrigir um cabeçalho do tipo de conteúdo, isso prejudicará os clientes?


14

Estamos executando uma API com muitas pessoas usando. Devido a alguma falta de jeito herdada da minha parte, um dos pontos de extremidade está retornando o cabeçalho do tipo de conteúdo errado , jsquando deveria json. Minha pergunta é: se corrigirmos isso trocando para retornar o valor correto, o quanto isso poderia atrapalhar as coisas para nossos clientes existentes? Ou, de outra forma, você esperaria que muitas bibliotecas clientes HTTP diferentes gerassem erros fatais ao ver uma alteração dessas?

Estamos tentando decidir se é uma mudança que podemos seguir em frente e fazer sem suar demais, ou devemos enviar um email com cuidado a todos os usuários e anunciar um período de descontinuação de vários anos ... ou algo assim.

Provavelmente depende um pouco do tipo de clientes HTTP diferentes em uso, então dei uma olhada nos agentes do usuário. Resposta: muitas diferentes! Aqui estão alguns dos principais:

"okhttp / 3.2.0", "requisições python / 2.10.0", "Ruby", "requisições python / 2.7.0", "Mozilla / 5.0", "Java / 1.8.0_91", "requisições python /2.4.3 "," okhttp / 3.3.0 "," Lucee "," Dalvik / 2.1.0 "," Google-HTTP-Java-Client / 1.21.0 "," PHP_appname "," NativeHost "," Java /1.7.0_67 "," Apache-HttpClient / UNAVAILABLE "," Dalvik / 1.6.0 "," Web-sniffer / 1.1.0 "," unirest-objc / 1.1 "

Várias bibliotecas de idiomas diferentes para dispositivos móveis e servidores. Principalmente não navegadores que executam javascript, mas alguns deles também.

A maioria das pessoas parece não perceber que o tipo de conteúdo está errado, mas de vez em quando aparece uma nova solicitação de suporte reclamando sobre esse problema, por isso gostaríamos de corrigi-lo.


4
Suponho que os clientes que funcionam corretamente com um cabeçalho de tipo de conteúdo incorreto não parem de funcionar depois que você definir o correto, mas você sabe o que eles dizem sobre suposições. Portanto, teste, comunique suas alterações à sua base de usuários com antecedência e / ou construa uma lógica adicional de que, se um determinado cliente quebrar, você poderá detectar esse cliente em particular e continuar retornando o cabeçalho do tipo de conteúdo incorreto (ou faça o inverso, retorne o correto para os clientes que geram tíquetes de suporte e mantêm tudo igual para os usuários / agentes do usuário atuais).
HBruijn

5
xkcd obrigatório: xkcd.com/1172
njzk2

Você não está versionando sua API?
Michael Hampton

Nós temos apenas um número de versão principal para toda a API, que procuraríamos apenas em alguns anos, quando fizermos algumas reestruturações bastante importantes. Nesse ponto, resolveríamos esse problema, é claro, mas ... parece que talvez nunca façamos isso. É um desses números de versão.
Harry Wood

Respostas:


30

quão mal poderia atrapalhar as coisas para nossos clientes existentes?

Isso poderia afundar completamente seus navios de guerra se eles escrevessem um código que se baseie nesse tipo de conteúdo incorreto.

Eu não esperaria que as bibliotecas gerassem erros, mas espero que, em alguns casos, as bibliotecas estritas tenham seu comportamento substituído para manipular o tipo MIME incorreto.

Se sua API tiver um valor de versão / revisão em um campo de solicitação em algum lugar, aumente e, na nova versão, retorne o tipo correto, mas continue retornando o tipo incorreto nas versões mais antigas. Se você não possui um campo de solicitação, agora é uma boa hora para adicionar um.


6
+1 já por um bom hipérbole
HBruijn

4
Muitas vezes você não tem escolha. Os clientes que recebem um ultimato "atualizar ou sair" podem decidir sobre o último, bom em princípio, ruim na prática. A versão antiga pode ser desativada ao longo do tempo.
alzee

3
Marque uma versão com +1 das solicitações, embora você queira dar uma olhada em en.wikipedia.org/wiki/Software_versioning para obter mais informações.
SBoss

7
@WinstonEwert: Claro que vale a pena. As pessoas especificam qual versão da API desejam usar e o programa não entra em combustão espontânea no tempo entre a atualização da API e a atualização do programa. Se você não fizer isso, interromperá automaticamente todas as versões atuais e históricas do código de seus clientes quando alterar sua interface. E essa é uma maneira terrível de executar um serviço.
Lightness Races com Monica

1
Este parece ser um ponto muito bom, a propósito: "Espero que, em alguns casos, bibliotecas estritas tenham tido seu comportamento substituído para lidar com o tipo MIME incorreto" Meu palpite (como resposta a toda a pergunta) é que a grande maioria dos clientes as bibliotecas ficarão bem com isso, mas isso é uma preocupação. Alguns clientes podem ter trabalhado proativamente com isso, e as trocas serão interrompidas por eles. Eu me pergunto o quanto disso aconteceu.
Harry Wood

11

Você esperaria que muitas bibliotecas clientes HTTP diferentes gerassem erros fatais ao ver uma alteração dessas?

Não. Toda biblioteca de cliente HTTP que eu conheço ignorará o cabeçalho do tipo de conteúdo, a menos que o programador leia especificamente esse cabeçalho e faça algo com ele. Posso imaginar uma biblioteca em que o tipo de conteúdo: application / json automaticamente faz com que um analisador de json se envolva, mas não conheço nenhum caso em que isso realmente ocorra.

A maioria das pessoas parece não perceber que o tipo de conteúdo está errado, mas de vez em quando aparece uma nova solicitação de suporte reclamando sobre esse problema, por isso gostaríamos de corrigi-lo.

Como eles perceberam o cabeçalho incorreto? Pode valer a pena olhar para isso, porque se o cabeçalho incorreto estava realmente causando problemas, eles claramente não estavam apenas ignorando-o e podem ter problemas se for corrigido.



Se você usa jQuery $.ajaxe não especifica a dataType:opção, ele infere o tipo de resposta do Content-typecabeçalho. Portanto, se for application/json, ele será analisado automaticamente antes de repassá-lo ao chamador.
Barmar

6

Difícil de distinguir sem receber aprovação de todos os seus clientes. Sugiro que você siga uma das duas abordagens a seguir para atualizar sua API para a v.Next.

  1. Estenda a API existente. Adicione uma string de consulta ou alguma outra variável à sua API que signifique usar a v.Next. Para todas as solicitações que usam essa variável, use o tipo de conteúdo atualizado.
  2. Execute uma instância de preparação ou pré-produção da sua API em paralelo com a API atual. Deve ser quase idêntico à produção. Mesmo usando o mesmo back-end. Embora este tenha as alterações propostas para v.Next.

Em qualquer um dos cenários, comunique aos seus clientes as alterações que você deseja fazer e a data / hora de transição desejada. Incentive-os a testar bem antes da data prevista para garantir que não haja interrupção do serviço.

Verifique se você possui uma página dedicada detalhando as alterações feitas na v.Next. Isso deve ser incluído nas comunicações enviadas aos seus clientes. Se você discutiu alguma correção com clientes existentes, inclua-as nesta página.

Por fim, trote a linha entre a comunicação excessiva com os clientes e o envio de spam. Essas notificações podem ser facilmente ignoradas à medida que surgem prioridades mais imediatas / urgentes.

FWIW, se as coisas estão funcionando atualmente, eu não me preocuparia muito com isso. Se, por exemplo, você achar que isso causa uma vulnerabilidade de segurança significativa, seria um ótimo motivo para promover essa alteração. Caso contrário, eu esperaria algo mais urgente para incluir essa alteração.


Obrigado. Não é a resposta que eu queria ouvir, mas talvez você esteja certo. Nós apenas precisamos introduzir a mudança com muito cuidado. É "muito difícil de dizer"? Eu acho que eu estava esperando que algumas pessoas teriam experiência do provável impacto deste tipo particular de mudança do tipo de conteúdo cabeçalho (deixando de lado os pontos mais genéricas sobre versionamento cautelosamente)
Harry Madeira

5

Aqui está um exemplo de uma biblioteca (bem, comando único) que isso quebraria:

O cmdlet do Invoke-RestMethod age de maneira diferente com o JSON. Se o resultado da solicitação for JSON, XML ou ATOM / RSS (e acho que é baseado no cabeçalho), ele a analisa / desserializa e retorna objetos nativos, caso contrário, retorna os dados brutos.

Portanto, o código existente seria escrito para lidar com uma string (talvez passando-a para ConvertFrom-Json) e, de repente, começaria a falhar.



-2

Eu notei duas consequências:

  1. Algumas bibliotecas cliente não processam a resposta corretamente. Por exemplo, a resposta retorna uma sequência em vez de json ou uma matriz.
  2. A compactação nem sempre é aplicada.

Certamente é quem envia os dados, e não quem os recebe, que aplica a compressão?
TRiG 03/08/19
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.