web-dev-qa-db-fra.com

HTTP Get avec 204 sans contenu: est-ce normal

Est-ce une occurrence normale pour une requête HTTP GET d'avoir une réponse avec le code d'état 204 - No Content? Par exemple, est-ce sémantiquement correct par rapport à ce qu'un HTTP GET est censé accomplir? Je sais qu'un 204 - No Content est correct pour une HTTP POST Request. Pour la requête GET, si non les données doivent être renvoyées, le code d'état 204 est-il approprié? Dois-je utiliser 404, ou simplement m'en tenir à 200 pour réussir, mais avoir une réponse vide?

cas d'utilisation pour cette question est une application Java que j'écris pour Google App Engine. J'envoie une demande à un servlet, mais les données à envoyer retour au client sera transmis via une socket API de canal au lieu de dans la réponse HTTP. Actuellement, mon client envoie un POST sans contenu dans le corps de la demande et attend une réponse 204) à partir du servlet avant d'interroger le socket de l'API de canal. Comme aucune donnée n'est envoyée dans le corps de la demande, je me demande s'il est plus logique d'envoyer un GET au lieu d'un POST.

google-app-enginehttpgethttp-status-codeschannel-api
39
ecbrodie

204 Aucun contenu

Le serveur a répondu à la demande mais n'a pas besoin de renvoyer un corps d'entité et peut vouloir renvoyer une métainformation mise à jour. La réponse PEUT inclure une métainformation nouvelle ou mise à jour sous la forme d'en-têtes d'entité qui, s'ils sont présents, DEVRAIENT être associés à la variante demandée.

Selon le partie RFC pour le code d'état 204 , il me semble un choix valide pour une demande GET.

UNE 404 Not Found, 200 OK avec un corps vide et 204 No Content ont une signification complètement différente, parfois nous ne pouvons pas utiliser le bon code d'état mais pliez les règles et elles reviendront vous mordre un jour ou plus . Donc, si vous pouvez utiliser le bon code d'état, utilisez-le!

Je pense que le choix de GET ou POST est très personnel car les deux feront le travail mais je vous recommande de garder un POST au lieu d'un GET , pour deux raisons:

  • Vous voulez que l'autre partie (le servlet si je comprends bien) effectue une action sans en extraire certaines données.
  • Par défaut, les requêtes GET peuvent être mises en cache s'il n'y a aucun paramètre présent dans l'URL, un POST ne l'est pas.
44
Satevis

Votre combinaison actuelle d'un POST avec une réponse HTTP 204 est très bien.

L'utilisation d'un POST comme remplacement universel d'un GET n'est pas prise en charge par le RFC, car chacun a son propre but et sa propre sémantique.

Le but d'un GET est de récupérer une ressource. Par conséquent, bien qu'autorisé, un HTTP 204 ne serait pas le meilleur choix car le contenu IS attendu dans la réponse. Un HTTP 404 non trouvé ou un HTTP 410 Gone serait un meilleur choix si le serveur n'était pas en mesure de fournir la ressource demandée.

Le RFC appelle également spécifiquement un HTTP 204 comme réponse appropriée pour PUT, POST et DELETE, mais l'omet pour GET.

Voir le RFC pour la sémantique de GET .

Il existe d'autres codes de réponse qui pourraient également être renvoyés, indiquant aucun contenu, qui seraient plus appropriés qu'un HTTP 204.

Par exemple, pour un GET conditionnel, vous pourriez recevoir une réponse HTTP 304 non modifiée qui ne contiendrait aucun contenu corporel.

15
Russ Jackson

J'utilise GET/204 avec une collection RESTful qui est un tableau positionnel de longueur fixe connue mais avec des trous.

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
10
Steve Mitchell

Le POST/GET avec 204 semble bien à première vue et fonctionnera également.

La documentation indique, 2xx - Cette classe de codes d'état indique que l'action demandée par le client a été reçue, comprise, acceptée et traitée avec succès. tandis que 4xx - La classe de code d'état 4xx est destinée aux situations dans lesquelles le client semble s'être trompé.

Depuis, la demande a été reçue, comprise et traitée avec succès sur le serveur. Le résultat est que la ressource est introuvable. Donc, dans ce cas, ce n'était pas une erreur côté client ou le client n'a pas commis d'erreur.

Il doit donc s'agir d'un code série 2xx et non 4xx. L'envoi de 204 (sans contenu) dans ce cas sera mieux qu'une réponse 404 ou 410.

5
iosCurator