El recurso de destino tiene más de una representación, cada una con su propio identificador más específico, y se proporciona información sobre las alternativas para que el cliente (o User-Agent) pueda seleccionar una representación preferida redirigiendo su petición a uno o más de esos identificadores.
En otras palabras, el servidor desea que el agente de usuario participe en una negociación reactiva para seleccionar la(s) representación(es) más apropiada(s) para sus necesidades.
Si el servidor tiene una opción preferida, el servidor DEBERÍA generar un campo de cabecera Location que contenga la referencia URI de la opción preferida. El cliente PUEDE utilizar el valor del campo Location para la redirección automática.
Para los métodos de solicitud que no sean HEAD, el servidor DEBERÍA generar una carga útil (payload) en la respuesta 300 que contenga una lista de metadatos de representación y referencia(s) URI de la que el cliente pueda elegir la más preferida. El cliente PUEDE hacer una selección de esa lista automáticamente si entiende el tipo de medio proporcionado. Esta especificación no define un formato específico para la selección automática, ya que HTTP trata de mantenerse al margen de la definición de sus cargas útiles. En la práctica, la representación se proporciona en algún formato fácilmente analizable que se considera aceptable para el cliente, según lo determinado por el diseño compartido o la negociación de contenidos, o en algún formato de hipertexto comúnmente aceptado.
Una respuesta 300 es almacenable en caché por defecto; es decir, a menos que se indique lo contrario en la definición del método o en los controles explícitos de caché.
Nota: La propuesta original del código de estado 300 definía el campo de cabecera URI como una lista de representaciones alternativas, de forma que se pudiera utilizar para las respuestas 200, 300 y 406 y se transfiriera en las respuestas al método HEAD. Sin embargo, la falta de despliegue y el desacuerdo sobre la sintaxis hicieron que tanto URI como Alternates (una propuesta posterior) fueran eliminados de esta especificación. Es posible comunicar la lista utilizando un conjunto de campos de cabecera Link, cada uno con una relación de «alternate«, aunque el despliegue es un problema de huevo y gallina.
Referencias de programación del Código HTTP 300
- Symfony HTTP Status Constant
Response::HTTP_MULTIPLE_CHOICES
- Python2 HTTP Status Constant
httplib.MULTIPLE_CHOICES
- Python3+ HTTP Status Constant
http.client.MULTIPLE_CHOICES
- Python3.5+ HTTP Status Constant
http.HTTPStatus.MULTIPLE_CHOICES
- Go HTTP Status Constant
http.StatusMultipleChoices
- Rails HTTP Status Symbol
:multiple_choices
- .NET HTTP Status Constant
System.Net.HttpStatusCode.MultipleChoices
- C# HTTP Status Enum
HttpStatusCode.Ambiguous
- C# HTTP Status Enum (Alternative)
HttpStatusCode.MultipleChoices
- Rust HTTP Status Constant
http::StatusCode::MULTIPLE_CHOICES