É para ser consideradoboa prática parareutilizar códigos de status HTTP RFC assim, ou deveríamos serinventando novos que mapeiam exatamente às nossas razões de erro específicas?

Estamos projetando uma API de serviço da Web em torno de alguns aplicativos herdados.

Além das estruturas de dados JSON / XML no corpo da resposta, nosso objetivo é retornar códigos de status HTTP que façam sentido para caches da webe desenvolvedores.

Mas como mapear diferentes classes de erros nos códigos de status HTTP apropriados? Todos na equipe concordam com o seguinte:

GET / pacote / 1234 retorna404 não encontrado se 1234 não existir

GET / package / 1234 / next_checkpoint retorna400 Solicitação incorreta se "próximo_checkpoint"e 1234 são válidos para serem solicitados, mas o next_checkpont aqui não faz sentido ...

e assim por diante ... mas, em alguns casos, as coisas precisam ser mais específicas do que apenas "400" - por exemplo:

POST / expedição /? For_package = 1234 retornaFalha na pré-condição 412 se / expedição e pacote 1234 existem, MAS 1234 ainda não está pronto para expedição.

(Editar:Códigos de status no HTTP / 1.1 eCódigos de status no WebDAV ext.)