API indisponible ou données en retard : quelle réponse envoyer ?
dans Doctrine
Une dépendance ne répond plus : servir une copie, attendre ou refuser dépend de l’opération. Les réponses HTTP doivent rendre ce choix clair pour le client.
Liste des articles rédigés par les contributeurs, mis à disposition des visiteurs
dans Doctrine
Une dépendance ne répond plus : servir une copie, attendre ou refuser dépend de l’opération. Les réponses HTTP doivent rendre ce choix clair pour le client.
dans Doctrine
GET sert souvent les vues de lecture, tandis que les écritures demandent une décision métier. REST et CQRS se combinent sans imposer le même découpage.
dans Doctrine
Une réponse perdue ne signifie pas que l’opération a échoué. Méthodes HTTP, clés d’idempotence et suivi du résultat aident à réessayer sans créer de doublon.
dans Doctrine
Un agent doit pouvoir identifier le contrat utilisé et comprendre son évolution. Versions, dépréciation, liens et erreurs explicites facilitent la migration.
dans Doctrine
Un agent peut suivre les liens et les actions d’une API hypermédia. Voici comment cela fonctionne, ce que MCP apporte et les critères utiles pour choisir.
dans Doctrine
Avec htmx, le serveur renvoie des fragments HTML prêts à afficher. Cette approche simplifie certains écrans, avec des limites pour les usages très riches.
dans Doctrine
Une API peut utiliser les ressources et les méthodes HTTP sans proposer d’hypermédia. Ce choix influe sur la découverte des actions et l’évolution des clients.
dans Doctrine
Une réponse hypermédia contient des données, des liens et des actions. Le client suit ces indications, tout en partageant un vocabulaire clair avec le serveur.
dans Doctrine
REST décrit des contraintes d’architecture pour faire évoluer clients et serveurs. HTTP et JSON ne suffisent pas : les liens, le cache et les contrats comptent.