3
votes

Dois-je valider la réponse de l'API sur le client?

Disons que j'ai une application qui utilise l'API RESTFUL. Par exemple: j'envoie des demandes au point final: "/ products" et je reçois une réponse au format JSON. Ensuite, j'utilise ces données dans mon application SPA.

Après un certain temps, la forme de la réponse a été modifiée. Je n'ai pas été informé de ce fait. En conséquence, mon application SPA s'est plantée. Après modification, certaines des propriétés que j'utilisais dans mon application manquaient dans la réponse de l'API. Je peux éviter une telle situation, lorsque je validerais chaque réponse dans mon application SPA et que je mettrais une valeur d'espace réservé lorsqu'elle est manquante dans la réponse. Mais cela peut entraîner des problèmes de performances.

Quoi qu'il en soit, est-ce une bonne pratique de mettre la validation des réponses API du côté client?


0 commentaires

3 Réponses :


2
votes

Conformément à votre description et à mon expérience sur les API Restful, il n'y a pas de meilleure pratique à ce sujet, mais dans certains cas, les API prennent en charge plusieurs types de contenu personnalisés et acceptent des en-têtes qui incluent une version pour gérer la compatibilité descendante avec différentes versions de objets de transfert de données.

Si vous n'avez pas accès à l'API que vous appelez, vous feriez mieux d'utiliser un modèle d'objet nul sur votre application côté client pour les valeurs manquantes afin d'éviter les plantages.


0 commentaires

3
votes

Je pense que le problème que vous rencontrez n'a pas vraiment à voir avec la validation, mais il a à voir avec la mise à jour de votre serveur d'une manière non rétrocompatible. Ce dont vous avez besoin est probablement une meilleure façon de gérer les mises à jour.

Je ne pense pas que télécharger occasionnellement un schéma et remplir aveuglément les propriétés manquantes soit la voie à suivre. Pouvez-vous créer votre service de manière à ce qu'il soit rétrocompatible? Si vous devez interrompre la rétrocompatibilité, avez-vous une bonne raison et y a-t-il un moyen sensé pour le client de la prendre en charge ou avez-vous besoin de mettre à jour le client?

Si vous contrôlez le serveur et le client, une stratégie qui a fonctionné pour moi était:

  1. N'effectuez pas de modifications radicales tout de suite. Mettez d'abord à jour le serveur vers la nouvelle version et dans une mise à jour ultérieure, arrêtez de prendre en charge une version précédente.
  2. Les clients peuvent parfois vérifier les versions prises en charge par un serveur. S'ils découvrent que le serveur a abandonné la prise en charge d'une version utilisée par le client, mettez à jour le client. (peut-être juste un rafraîchissement?)

Mais c'est assez large. Je ne sais pas exactement à quel point cela vous aidera car cela dépend assez de la situation.


0 commentaires

0
votes

Tout ce dont vous avez besoin est d'introduire la gestion des versions d'API dans votre projet. Ainsi, votre client peut compter sur certaines versions jusqu'à ce que vous décidiez d'aller plus loin. Le développement du client et du serveur devient plus indépendant l'un de l'autre.


0 commentaires