J'essaie des codes de réponse JSON et HTTP. Je soumets un formulaire via une demande Ajax et j'ai évidemment besoin de valider les données sur le côté serveur.
Mon idée est de répondre avec une réponse "200 OK" (avec un message de confirmation comme le corps) si le poste est réussi. Je ne sais pas quoi répondre avec si les données qui envoient l'utilisateur sont invalides.
7 Réponses :
Vous pouvez envoyer un 400: mauvaise demande en-tête. Si ce n'est pas votre tasse de thé, vérifiez peut-être le Les définitions de code d'état de W3C ?
Si ce n'est pas votre tasse de thé: 418 Je suis une théière
Voici le liste complète de code d'état HTTP. Le premier qui ressort à l'esprit de votre situation est de 400 mauvaises demande, mais c'est généralement utilisé pour indiquer une erreur dans la syntaxe HTTP plutôt qu'une erreur dans la teneur en corps. Néanmoins, sans plus d'informations, j'irais avec celui-là.
Dans des cas spécifiques, en fonction de la nature exacte des données que vous recevez, je pouvais voir l'un des 403, 404, 410, 413, ou peut-être d'autres étant la réponse appropriée.
La liste complets la liste des codes d'état est dans le registre IANA: IANA .org / assignations / codes d'état HTTP
Envoyer un objet JSON:
$message = array( 'error' => true, 'code' => 'some error number relevant to you', 'message' => 'A nice human-readable+relevant error message' ); echo json_encode($message);
+1: C'est ce que j'avais trouvé lors de la lecture sur cette même chose récemment: Statut HTTP! = Statut des données utilisateur
En fait, le code d'état HTTP 400 était destiné à cela, il devrait donc "sembler juste". Mais cela n'aide pas beaucoup les développeurs au cas où il s'agit d'une API publique.
Marc B - qui abuse HTTP comme tunnel. C'est un protocole de couche d'application, donc 4xx est la bonne classe d'erreur.
Renvoyer 404 pour une demande Ajax sur un enregistrement qui n'existe pas dans la DB ne fait que mal ... Le script de gestionnaire Ajax est présent et travaillant, ce que la demande HTTP a été placée. Renvoyer un HTTP 404 pour dire "Aucun enregistrement trouvé" implique que le script Ajax n'était pas trouvé, ce qui n'est pas le cas.
Marc B - Nonsense. HTTP consiste à accéder aux ressources. Cela n'a tout à fait pas d'importance comment le serveur fonctionne en interne. Ce qui compte, c'est la ressource identifiée par l'URI HTTP et l'opération demandée par le client.
Exactement. et Ajax est superposé sur HTTP. Utilisation des codes d'état HTTP pour signifier les défaillances AJAX confond simplement le problème. Si vous conduisez au cinéma (http) mais oubliez votre portefeuille (AJAX) afin que vous ne puissiez même pas acheter un billet, faites-vous blâmer HTTP ou AJAX? Le retour d'un portefeuille 404 non trouvé n'a pas de sens pour le navigateur, car 404 signifie que MOVIEETHEARE.COM/AJAX.PHPOFEDO/AJA > n'existe pas. Cela ne signifie pas que ... ajax.php? portefeuille = 50dollars n'est pas présent.
@MARC: Cela signifie que la ressource n'est pas trouvée. Cela signifie donc la ressource identifiée par l'URL (l'identifiant de portefeuille) introuvable. Donc, dans ce cas, oui un 404 serait approprié ...
Marc B: Le "X" dans Ajax est pour XHR. XHR n'est pas superposé sur HTTP; C'est une API pour HTTP.
La manière dont je vois généralement que cela est fait, c'est que vous laissez les codes de réponse HTTP à utiliser pour des éléments liés au protocole HTTP, pas pour les erreurs de votre application. Ensuite, à partir de votre réponse HTTP, vous renvoyez JSON qui indique le succès ou l'échec et les données renvoyées souhaitées. Par exemple, vous pouvez renvoyer ceci:
{
statusCode: 0, // 0 = successful, negative value = error code
statusMsg: "success", // you can put any human readable status msg here
data: {
confirmationMsg: "Data sent successfully."
}
}
dépend du but de l'API. Si c'est le vôtre (privé), répondez à l'état HTTP 400 en tant que nightfirecat suggéré. Si c'est une API publique, envoyez un message d'erreur significatif pour aider les développeurs.
Il suffit de mettre en place un protocole standard comme JSON-RPC . Il a une manipulation des erreurs, une passage de paramètres, etc.
demande: p> réponse: p> et sur erreur : P> {"result": null, "error": "Duplicate Message", "id": 99}
Wow, même "standard" dans gras .
:-D C'est une pierre de messe de la mienne que les gens continuent à inventer leurs propres protocoles (et il y a des tonnes d'acclamations majeures données à celles qui font). Ne faites pas la vôtre sauf si un existant ne peut vraiment pas faire ce dont vous avez besoin (et vous êtes sûr d'en avoir besoin) ...
Je n'invie pas mon propre protocole. Ma logique était que la méthode de JQuery's $ .Ajax peut exécuter différentes fonctions en fonction du code de réponse. Donc, s'il y avait une réponse d'erreur, le message retourné serait traité différemment. Mais j'ai accepté cette réponse comme vous avez probablement raison de dire que c'est la bonne chose à faire.
soit 400 (générique), ou si vous souhaitez être plus spécifique: http: / /greenbytes.de/tech/webdav/rfc4918.html#status_422