¿Es para ser consideradobuena práctica areutilizar códigos de estado HTTP RFC así, o deberíamos serinventando nuevos que mapean exactamente a nuestras razones de error específicas?

Estamos diseñando una API de servicio web en torno a un par de aplicaciones heredadas.

Además de las estructuras de datos JSON / XML en el cuerpo de respuesta, nuestro objetivo es devolver códigos de estado HTTP que tengan sentido para las memorias caché weby desarrolladores

Pero, ¿cómo hace para mapear diferentes clases de errores en los códigos de estado HTTP apropiados? Todos en el equipo están de acuerdo en lo siguiente:

OBTENER / paquete / 1234 devoluciones404 No encontrado si 1234 no existe

GET / package / 1234 / next_checkpoint devoluciones400 Petición Incorrecta si "next_checkpoint"y 1234 son válidos para solicitar, pero next_checkpont aquí no tiene sentido ...

y así sucesivamente ... pero, en algunos casos, las cosas deben ser más específicas que solo "400", por ejemplo:

POST / dispatch /? For_package = 1234 devoluciones412 Precondición fallida si / dispatch y el paquete 1234 existen, PERO 1234 aún no está listo para el envío.

(Editar:Códigos de estado en HTTP / 1.1 yCódigos de estado en WebDAV ext.)