google app engine - google - HTTP Get with 204 Sin contenido: ¿Es eso normal?
google app engine python (4)
204 Sin contenido
El servidor ha cumplido la solicitud pero no necesita devolver un cuerpo de entidad, y puede querer devolver metainformación actualizada. La respuesta PUEDE incluir metainformación nueva o actualizada en forma de encabezados de entidad, que de estar presentes DEBERÍAN asociarse con la variante solicitada.
De acuerdo con la parte de RFC para el código de estado 204 , me parece una opción válida para una solicitud GET.
Un 404 Not Found , 200 OK con el cuerpo vacío y 204 No Content tienen un significado completamente diferente, a veces no podemos usar el código de estado adecuado, pero doblamos las reglas y volverán para morderte un día o más tarde . Entonces, si puedes usar el código de estado apropiado, úsalo.
Creo que la elección de GET o POST es muy personal, ya que ambos harán el trabajo, pero les recomendaría que guarden un POST en lugar de un GET, por dos razones:
- Desea que la otra parte (el servlet si lo entiendo correctamente) realice una acción y no recupere algunos datos de ella.
- De forma predeterminada, las solicitudes GET se pueden almacenar en caché si no hay parámetros presentes en la URL, una POST no.
¿Es normal que una solicitud HTTP GET tenga una respuesta con el código de estado 204 - No Content ? Me gusta, ¿esto es semánticamente correcto con respecto a lo que se supone que debe lograr un HTTP GET? Sé que un 204 - No Content está bien para una solicitud HTTP POST . Para la solicitud GET, si no se van a enviar datos, ¿es apropiado el código de estado 204? ¿Debería usar 404 o simplemente mantener 200 para tener éxito pero tener una respuesta vacía?
El caso de uso para esta pregunta es una aplicación Java que estoy escribiendo para Google App Engine. Estoy enviando una solicitud a un servlet, pero los datos que se enviarán al cliente se transmitirán a través de un socket API de canal en lugar de en la respuesta HTTP. Actualmente, mi cliente envía un mensaje POST sin contenido en el cuerpo de la solicitud y espera una respuesta 204 desde el servlet antes de sondear el socket de API del canal. Como no se envían datos en el cuerpo de la solicitud, estoy debatiendo si tiene más sentido enviar un GET en lugar de un POST.
El POST / GET con 204 parece estar bien a primera vista y también funcionará.
La documentación dice, 2xx: esta clase de códigos de estado indica que la acción solicitada por el cliente fue recibida, entendida, aceptada y procesada con éxito. mientras que 4xx - El código de estado de la clase 4xx está destinado a situaciones en las que el cliente parece haber cometido un error.
Desde entonces, la solicitud fue recibida, entendida y procesada exitosamente en el servidor. El resultado fue que el recurso no se encontró. Por lo tanto, en este caso, esto no fue un error en el lado del cliente o el cliente no se ha equivocado.
Por lo tanto, este debería ser un código serie 2xx y no 4xx. Enviar 204 (No encontrado) en este caso será mejor que una respuesta 404 o 410.
Su combinación actual de un POST con una respuesta HTTP 204 está bien.
El RFC no admite el uso de un POST como reemplazo universal para un GET, ya que cada uno tiene su propio propósito y semántica específicos.
El propósito de un GET es recuperar un recurso. Por lo tanto, aunque está permitido, un HTTP 204 no sería la mejor opción, ya que se espera que el contenido sea la respuesta. Un HTTP 404 no encontrado o un HTTP 410 Gone serían mejores opciones si el servidor no pudiera proporcionar el recurso solicitado.
El RFC también llama específicamente un HTTP 204 como respuesta apropiada para PUT, POST y DELETE, pero lo omite para GET.
Ver el here .
Hay otros códigos de respuesta que también podrían devolverse, indicando que no hay contenido, que serían más apropiados que un HTTP 204.
Por ejemplo, para un GET condicional, podría recibir una respuesta HTTP 304 No modificada que no contendría ningún contenido corporal.
Yo uso GET / 204 con una colección RESTful que es una matriz posicional de longitud fija conocida pero con agujeros.
GET /items
200: ["a", "b", null]
GET /items/0
200: "a"
GET /items/1
200: "b"
GET /items/2
204:
GET /items/3
404: Not Found