HTTP Get avec 204 No Content : Est-ce normal ?

Question

Est-il normal qu'un Demande HTTP GET pour obtenir une réponse avec le code d'état 204 - No Content ? Est-ce que c'est sémantiquement correct par rapport à ce qu'un GET HTTP est censé accomplir ? Je sais qu'un 204 - No Content est ok pour un HTTP POST-Request . Pour une requête GET, si aucune donnée ne doit être renvoyée, le code d'état 204 est-il approprié ? Devrais-je utiliser le code 404, ou m'en tenir au code 200 en cas de succès, mais avoir une réponse vide ?

En cas d'utilisation pour cette question est une application Java que j'écris pour Google App Engine. J'envoie une requête à une servlet, mais les données à renvoyer au client seront transmises par un socket Channel API au lieu de la réponse HTTP. Actuellement, mon client envoie un POST sans contenu dans le corps de la requête et attend une réponse 204 de la servlet avant d'interroger le socket Channel API. Étant donné qu'aucune donnée n'est envoyée dans le corps de la requête, je me demande s'il est plus judicieux pour moi d'envoyer un GET plutôt qu'un POST.

Answer 1

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

Answer 2

204 Pas de contenu

Le serveur a satisfait à la demande mais n'a pas besoin de renvoyer un message corps de l'entité, et peut vouloir renvoyer des méta-informations mises à jour. La réponse de réponse PEUT inclure des méta-informations nouvelles ou mises à jour sous la forme de d'en-têtes d'entité qui, s'ils sont présents, devraient être associés à la variante variante demandée.

Selon le Partie du RFC pour le code d'état 204 il me semble que c'est un choix valable pour une requête GET.

A 404 Not Found , 200 OK avec un corps vide et 204 No Content ont des significations complètement différentes, parfois nous ne pouvons pas utiliser le code de statut approprié mais contournez les règles et elles reviendront vous mordre un jour ou l'autre. . Donc, si vous pouvez utiliser un code d'état approprié, utilisez-le !

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

• Vous voulez que l'autre partie (la servlet si j'ai bien compris) exécute une action et non pas qu'elle récupère des données.
• Par défaut, les demandes GET peuvent être mises en cache si aucun paramètre n'est présent dans l'URL, ce qui n'est pas le cas des demandes POST.

Answer 3

Votre combinaison actuelle d'un POST avec une réponse HTTP 204 est parfaite.

L'utilisation d'un POST comme remplacement universel d'un GET n'est pas soutenue par la RFC, car chacun a son propre objectif et sa propre sémantique.

Le but d'un GET est de récupérer une ressource. Par conséquent, bien qu'il soit autorisé, un HTTP 204 n'est pas le meilleur choix puisque la réponse doit contenir du contenu. Une adresse HTTP 404 Non trouvé ou un HTTP 410 disparu seraient de meilleurs choix si le serveur était incapable de fournir la ressource demandée.

La RFC indique aussi spécifiquement qu'une HTTP 204 est une réponse appropriée pour PUT, POST et DELETE, mais l'omet pour GET.

Voir le RFC pour la sémantique de GET .

D'autres codes de réponse peuvent également être renvoyés, indiquant l'absence de contenu, qui seraient plus appropriés qu'un HTTP 204.

Par exemple, pour un GET conditionnel, vous pourriez recevoir un HTTP 304 Non modifié qui ne contiendrait pas de corps de réponse.

Answer 4

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

La documentation dit, 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. considérant que 4xx -- La classe de codes d'état 4xx est destinée aux situations dans lesquelles le client semble avoir commis une erreur.

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

Il devrait donc s'agir d'un code de série 2xx et non 4xx. L'envoi de 204 (No Content) dans ce cas sera préférable à une réponse 404 ou 410.

Answer 5

Un Http GET retournant 204 est parfaitement acceptable, tout comme un retour 404.

L'important est que vous définissiez les normes/lignes directrices de conception de votre API, afin que tous vos points d'extrémité utilisent les codes d'état de manière cohérente.

Par exemple :

• vous pouvez indiquer qu'un point de terminaison GET qui renvoie une collection de ressources retournera 204 si la collection est vide. Dans ce cas GET /complaints/year/2019/month/04 peut revenir à 204 si aucune plainte n'est déposée en avril 2019. Il ne s'agit pas d'une erreur du côté client, et nous renvoyons donc un code d'état de réussite (204). PAR CONTRE, GET /complaints/12345 peut retourner 404 si le numéro de plainte 12345 n'existe pas.
• si votre API utilise HATEOAS, 204 est probablement une mauvaise idée car la réponse doit contenir des liens permettant de naviguer vers d'autres états.