Serviço Web REST: Tipo de conteúdo de resposta HTTP aceitável ao responder com status 4XX (Erro do Cliente)
Não consegui encontrar nenhuma documentação nas especificações HTTP que determinam se é aceitável gerar uma resposta HTTP incluir uma mensagem de erro legível (por exemplo, tipo de conteúdo: text / plain) se um cliente HTTP tiver feito uma solicitação HTTP inválida, e especificou um cabeçalho de solicitação que limita os tipos de conteúdo de resposta aceitáveis usando um cabeçalho de aceitação.
Imagine um cliente de serviço da web REST emitindo uma solicitação GET inválida para "http: // myhost / validpath? IllegalRequestParameter = rubbish" e incluindo um cabeçalho de solicitação "Accept: application / xml" ou "Accept: application / vnd.ms-excel" .
O servidor responderia com um código de status HTTP na série 4XX ("400 Bad Request", neste caso). Mas como o serviço seria capaz de transmitir informações ao cliente sobre a causa do erro?
Eu vejo as seguintes opções:
Crie uma mensagem de erro em texto simples no conteúdo da resposta HTTP. Defina o cabeçalho de resposta "Content-type: text / plain" e inclua uma mensagem de erro descritiva no conteúdo da resposta. Isso, no entanto, quebraria a restrição "Aceitar" do cliente HTTP.
Não inclua um conteúdo de resposta HTTP. Isso é claramente válido, mas não é muito útil para o cliente que apenas sabe que ocorreu um "Erro do cliente", mas não tem como saber o motivo (e relatar o motivo em um arquivo de log do cliente).
Tente forçar uma mensagem de erro em um tipo MIME "Aceitável". Isso raramente é possível. Mesmo que a mensagem de erro possa ser construída como um tipo de aplicativo / xml válido, ela provavelmente quebraria um contrato de serviço da Web (por exemplo, conformidade com o XML Schema).
Minha pergunta é: a situação acima é governada por especificações / padrões HTTP existentes?
Referências:
Definições de Código de Status HTTP:http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlDefinições de campo de cabeçalho HTTPhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html