O cliente faz solicitações consistentemente com o cabeçalho de aceitação de 'application / json' e o tipo de conteúdo de 'application / json'
Sim, é a coisa certa a fazer, mas não significa que o fornecedor se importe. Embora eu compreenda totalmente sua frustração, porque também acho que um serviço JSON sempre deve dar uma resposta JSON, mas há muitos exemplos em que esse não é o caso.
Ao longo do projeto, essa mesma prática foi aplicada a dois fornecedores diferentes e a dois serviços diferentes. Eu me vi justificando por que os serviços precisavam ser alterados. Os fornecedores declararam que o cliente deve lidar com isso e até minha biblioteca REST de escolha foi questionada (RestEasy) porque não lida com isso por padrão 'pronto para uso'.
Bem, eu tenho que concordar com o fornecedor. É o serviço deles e, desde que documentem claramente os casos especiais para usá-lo, não será possível impor que eles o alterem. É uma desvantagem para eles, pois os desenvolvedores demoram a adotar sua API e, se ouvissem o que os desenvolvedores precisam, eles a alterariam, mas, infelizmente, não há regra de que eles devem seguir os padrões.
A questão é: estou perdendo alguma coisa?
Os cabeçalhos de solicitação não significam nada, a menos que sejam interrompidos corretamente na outra extremidade. Eu sei que, se eu desenvolver uma API da web usando PHP, vá para o inferno com os cabeçalhos de solicitação. Eu posso responder com o que eu quiser. Visto que um serviço configurado no IIS com C # oferece um tratamento muito mais fácil dos cabeçalhos de solicitação, seu tipo e o tipo de resposta. Tem muito a ver com as ferramentas que o fornecedor usou para criar a API.
Eu estou sendo pedante sobre isso?
Sim e não. Tenho amigos de desenvolvedores que não conseguiriam superar isso. Eles ficariam tão fixados pelo problema e incapazes de prosseguir com outras tarefas até que a API funcionasse da maneira que eles esperavam. Agora isso está sendo pedante.
É um problema porque o fornecedor criou "mais trabalho" para concluir suas tarefas. Qualquer um ficaria frustrado com isso. Eu sei que seria.
É bom ter uma API JSON que não tenha um tipo de conteúdo de application / json nesse cenário?
Absolutamente, mas não é uma boa prática.
Um cliente pode apenas dizer ao servidor qual é o tipo de contexto de um request
. Não tem capacidade de impor um tipo de conteúdo para o response
. O cliente pode apenas informar ao servidor que fará accept
uma coleção de possíveis tipos de conteúdo.
Definições de campo de cabeçalho
O campo Aceitar cabeçalho da solicitação pode ser usado para especificar certos tipos de mídia aceitáveis para a resposta. Os cabeçalhos de aceitação podem ser usados para indicar que a solicitação é especificamente limitada a um pequeno conjunto de tipos desejados, como no caso de uma solicitação de uma imagem em linha.
É possível que um cliente solicite uma imagem de image/jpeg
, mas o servidor responde com text/html
e um código de status 404
se a imagem não foi encontrada. Os servidores também podem responder incorretamente. Existem muitos sites Wordpress por aí que respondem com text/html
e código de status 200
para arquivos não encontrados.
Agora, essa é toda a prática MAU por parte do servidor. O que estou tentando lhe dizer é que é absolutamente possível e acontece com frequência. As pessoas não sabem o que estão fazendo quando configuram essas coisas.
Referências seriam apreciadas. Como você resolve essa situação do ponto de vista comercial?
Eu já tive esse problema em alguns projetos. Você post
envia dados JSON para o servidor e ele retorna uma resposta JSON ou HTML.
Realmente não é grande coisa saber que tipo estava na resposta. Se o primeiro caractere for {
ou [
você pode assumir JSON. Se for, <
você pode assumir HTML. É assim que eu lidei com isso no passado. Às vezes, o programador que escreveu a API sabe tudo sobre os cabeçalhos HTTP. Tudo volta como text/html
respostas. Se você tiver sorte, eles têm o Apache configurado como padrão, o text/plain
que às vezes pode ajudar.
Esses problemas existem e continuarão a existir no futuro. A comunicação entre servidores é de longe uma atividade não regulamentada. Não existe um órgão de administração que expulse um fornecedor de uma união para um servidor que fornece respostas HTTP incorretas.