Pour gérer proprement les erreurs dans les réponses d'un API REST, le mieux est de n'utiliser que les "Status Code" HTTP (404, 400, ...). Parfois cela ne suffit pas.
Dans ce cas, le mieux est d'utiliser :
Vu qu'on utilise déjà ce type de mécanisme aujourd'hui, je pense qu'au moins l'un des deux sera très vite adopté et qu'on s'y retrouvera beaucoup plus rapidement en découvrant une nouvelle API !
Le HTTP Status Code est toujours très utile pour faire des API REST utilisables. Bien souvent, on n'a même plu besoin de rajouter un bête "status" ou "error code" dans les réponses, un simple HTTP Status Code suffit amplement.
Cet article est pas mal du tout sur le sujet. Merci Seb Sauvage.
Convention REST : le nom des ressources est au pluriel et puis c'est tout.
Pour GET et DELETE, c'est assez clair :
GET resources (accès à toutes les ressources)
GET resources/123 (accès à la ressource 123)
DELETE resources/123 (supprime la ressource 123)
Même en omettant la question du POST / PUT, ça reste bizarre pour la création /update :
POST resources (créé / modifie une ressource, ou une liste de ressources)
Moi j'aurai tendance à faire POST resources pour une liste, POST resources/123 pour une ressource.
Cette bibliothèque Qt pour lancer un serveur ou un client HTTP semble idéale (licence MIT). Plus aboutie que QHttpServer (https://github.com/nikhilm/qhttpserver, licence MIT aussi).
ça fait plusieurs développeurs Node.js que je vois aussi faire du C++ avec beaucoup de talent. C'est bien les gars ;-)
Ce topic est à lire en détail ! C'est un sujet qui m'intéresse et me passionne tout à la fois en ce moment. Mais le plus frustrant c'est qu'il est particulièrement difficile d'atteindre le système fiable et sûre à 99%. J'aimerai le créer au moins une fois, quit à le rendre non user-friendly, histoire de pouvoir faire correctement ma sauce dans de vrais projets.