Discussion :

[jojo_ol76]

Bonjour,

J'ai effectué une application android qui va communiquer avec un serveur qui va effectuer du traitement sur une base de donnée.

La question est-celle-ci: les codes erreurs HTTP 200 ... sont gérer par le développeur du site web ou c'est généré automatiquement dans la couche basse.

Par exemple , je vais effectuer une requête POST avec un paramètre qui se trouve être un numéro de Livre .

Je souhaiterais que le serveur me réponde par un code retour si la requête est correcte puis par un autre code si le livre existe ou pas.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
StatusLine statusLine = response.getStatusLine();
if (statusLine.getStatusCode() == HttpStatus.SC_OK) {
 
}

Pouvez vous me dire comment c'est gérer?

Merci.

[MrDuChnok]

Les codes de retours HTTP sont comme leur nom l'indiques liées au protocole HTTP.
Y inclure des règles métiers va plus te pertuber qu'autre chose, du style du ne saura pas si c'est une erreur de communication ou une erreur du métier.
Il vaut mieux, à mon sens, que tu analyses plutôt le résultat (si la communication s'est bien déroulé) afin de savoir si ta requête post à bien été pris en compte par le serveur.

[jojo_ol76]

si le code retour est 200, le serveur doit m'envoyer du json ou xml par exemple (résultat de la requête).

[MrDuChnok]

oui c'est ça

[UbuntuMan]

ça dépend si tu fais du restfull le code HTTP a son importance.

ex : 404 = ressource not found veut dire que l’élément que tu recherches n'existe pas !

C'est bcp plus parlant que d'avoir 200 = ok, mais je regarde le message pour voir que l'objet n'a pas été trouvé

Mieux, si tu t'interface avec un portail qui nécessite une authent. Si l'authent
renvoie toujours 200, t'es comme un con a parser la réponse... alors qu'avec un code 401, ben là c'est plus clair.

Bon après chacun voit midi à sa porte

[nicroman]

Je suis "presque" d'accord.

On a effectivement 3 couches, à chaque couche ses erreurs
TCP/IP (IOException)
HTTP (200,404,500, ... StatusLine)
APPLICATION (à définir par l'applicatif)

Sauf que la couche HTTP est "prévue" pour fournir des informations applicatives (statuts 200,201,300,400,401,403,406,...). Et il serait bête de ne pas les utiliser pour cela.

Par exemple, si on parle de "REST" par exemple, l'URL décrit un livre, si ce livre n'existe pas le serveur DOIT retourner 404.
401/403 pour des problemes d'authentification.
406 si il ne peut pas fournir le type de rendu désiré (JSON par exemple)
etc...

Sans oublier 400, l'appelant a fait une bourde dans sa syntaxe !

Les codes retours HTTP doivent être pris en compte de toute manière...
200-299 => ok ca s'est bien passé
300-399 => ok, mais c'est pas complet
400-499 => pas ok, c'est un probleme coté application
500-599 => pas ok, c'est un probleme coté serveur

[jojo_ol76]

Si je souhaite juste tout simplement vérifier si un livre est présent ou pas,

Je peux me fier uniquement sur le code retour 404.

Concernant l'envoi de donné, est-ce que le code 200 suffit pour dire que cela a été transmis?

[jojo_ol76]

Est-ce que une réponse sous la forme JSON?:

{"status": 0 }

Sinon :

{"status": -1 }

J'utiliserais une méthode POST pour la vérification. une méthode POST afin de ne pas ajouter les paramètres dans l'URL.