Si j'exécute une API et que je corrige l'en-tête content-type, est-ce que cela aura des conséquences pour les clients ?

à quel point cela pourrait-il perturber les choses pour nos clients existants ?

Il pourrait complètement couler leurs cuirassés s'ils ont écrit du code qui repose sur ce Content-Type étant incorrecte.

Je ne m'attends pas à ce que les bibliothèques lancent des erreurs, mais je m'attends à ce que dans certains cas, les bibliothèques strictes aient eu leur comportement modifié pour gérer le type MIME incorrect.

Si votre API a une valeur de version/révision dans un champ de demande quelque part, augmentez-la, et dans la nouvelle version, renvoyez le type correct mais continuez à renvoyer le type incorrect dans les anciennes versions. Si vous ne disposez pas d'un tel champ de demande, c'est le moment d'en ajouter un.

S'attendrait-on à ce que de nombreuses bibliothèques de clients HTTP différentes lancent le fatal en présence d'un tel changement ?

Non. Chaque bibliothèque client HTTP que je connais ignore l'en-tête content-type, sauf si le programmeur lit spécifiquement cet en-tête et en fait quelque chose. Je peux imaginer une bibliothèque où le content-type : application/json entraîne automatiquement l'intervention d'un analyseur json, mais je ne connais aucun cas où cela se produit réellement.

La plupart des gens n'ont pas l'air de remarquer que le type de contenu est mauvais, mais mais de temps en temps, une nouvelle demande d'assistance apparaît pour se plaindre de ce problème. ce problème, alors nous aimerions le résoudre.

Comment ont-ils remarqué l'en-tête incorrect ? Cela pourrait valoir la peine de se pencher sur la question, car si l'en-tête incorrect leur a causé des problèmes, ils ne l'ont pas simplement ignoré, et ils pourraient avoir des problèmes s'il est corrigé.

Trop difficile à dire sans l'accord de tous vos clients. Je vous suggère d'adopter l'une des deux approches suivantes pour mettre votre API à niveau vers la version suivante.

1. Étendre l'API existante. Ajoutez une chaîne de requête ou une autre variable à votre API qui signifie l'utilisation de v.Next. Pour toutes les requêtes utilisant cette variable, utilisez le content-type mis à jour.
2. Exécutez une instance de Staging ou de Pre-Production de votre API en parallèle avec votre API actuelle. Elle doit être presque identique à la production. Même en utilisant le même back-end. Bien que cette instance contienne les changements proposés pour la prochaine version.

Dans un cas comme dans l'autre, communiquez à vos clients les changements que vous souhaitez apporter et la date et l'heure cibles de la transition. Encouragez-les à effectuer des tests bien avant la date cible pour vous assurer qu'il n'y a pas d'interruption de service.

Assurez-vous d'avoir une page dédiée détaillant les changements apportés à la v.Next. Cette page doit être incluse dans les communications envoyées à vos clients. Si vous avez discuté des corrections avec des clients existants, incluez-les dans cette page.

Enfin, veillez à ne pas trop communiquer avec vos clients et à ne pas les spammer. Ces notifications peuvent être facilement négligées au profit de priorités plus immédiates/urgentes.

Si les choses fonctionnent actuellement, je ne m'inquiéterais pas trop à ce sujet. Si, par exemple, vous découvrez que cela entraîne une vulnérabilité de sécurité importante, ce serait une excellente raison de publier cette modification. Sinon, j'attendrais quelque chose de plus urgent pour inclure cette modification.

Voici un exemple d'une bibliothèque (enfin, d'une seule commande) que cela casserait :

El powershell cmdlet Invoke-RestMethod agit différemment avec JSON. Si le résultat de la requête est JSON, XML ou ATOM/RSS (et je pense que c'est basé sur l'en-tête), il l'analyse/désérialise et renvoie des objets natifs, sinon il renvoie les données brutes.

Ainsi, le code existant serait écrit pour traiter une chaîne de caractères (peut-être en la passant à la fonction ConvertFrom-Json ), et commencerait soudainement à échouer.

J'ai remarqué deux conséquences :

1. Certaines bibliothèques clientes ne traiteront pas la réponse correctement. Par exemple, la réponse renvoie une chaîne au lieu de json ou d'un tableau.
2. La compression n'est pas toujours appliquée.