Un article récent faisant le point sur la gestion des #erreurs dans une appli #REST, #JSON ou #Atom par exemple. Trouvé par @denisb.
SOA Bits and Ramblings : #Error handling considerations and best practices
▻http://soabits.blogspot.fr/2013/05/error-handling-considerations-and-best.html
A recurring topic in REST and #Web #API discussions is that of error handling ; what information should be included in error responses, how should #HTTP status codes be used and what media type should the response be encoded in?
How would the client know how to decode the error response payload? Actually this seems like an unanswered question for ATOM since the spec is rather vague about this point
Ceci car je posais la question de savoir quoi renvoyer comme contenu (pas l’entête avec le code de statut quoi) lorsqu’une application #AtomPub (#APP) doit renvoyer une erreur (par exemple lorsqu’on veut accéder à une ressource précise qui n’existe pas, ou qu’on a pas les droits). En JSON c’est « facile » : il n’y a pas de norme sur son contenu, on met ce qu’on veut dedans suivant l’application, puis on le documente. Mais en ATOM c’est déjà normé, et on ne sait pas ce qu’on doit faire si une erreur arrive.
L’auteur fait un lien vers une proposition de nouveaux types MIME pour ça : « error+json » et « error+xml », qui seraient à utiliser pour n’importe quelle API basée sur HTTP.
▻https://tools.ietf.org/html/draft-nottingham-http-problem-03