Qu’est-ce qu’un service web ?

Un service web est une interface permettant à des applications d’échanger des données ou d’appeler des fonctions par le réseau. Un site web s’adresse d’abord aux personnes ; un service web fournit un contrat destiné aux logiciels clients. Un même produit peut offrir les deux. Beaucoup de services utilisent HTTP et JSON, mais d’autres protocoles et formats existent.

Déroulement d’un échange

Le client envoie une requête à un point d’accès défini avec une méthode, des paramètres et, si nécessaire, des identifiants. Le service valide la demande, exécute l’opération et renvoie une réponse. Dans une API HTTP, le code d’état distingue les grandes catégories : réussite, erreur côté client comme une entrée invalide, ou panne côté serveur. Le corps de la réponse apporte normalement des précisions dans un format documenté.

Un contrat clair définit chemins, méthodes, champs, types, authentification, limites de débit et erreurs. Les clients peuvent alors être développés indépendamment. Le versionnement importe : modifier le sens d’un champ peut casser des applications existantes même si l’adresse ne change pas. Respectez la compatibilité annoncée et publiez des délais avant la suppression d’une fonction.

REST, SOAP, GraphQL et webhooks

REST est un style d’architecture, pas un format unique. Les API HTTP dites RESTful représentent souvent des ressources par des URL et utilisent GET pour lire, POST ou PUT pour modifier. Une requête GET ne devrait pas créer de changement durable, car clients et intermédiaires peuvent la répéter ou la mettre en cache. SOAP utilise des messages XML structurés et des descriptions de service formelles dans de nombreux systèmes professionnels.

GraphQL permet au client de demander certains champs par l’intermédiaire d’un schéma, souvent sur HTTP. Il peut réduire les données inutiles, mais complique parfois le coût des requêtes, l’autorisation et le cache. Un webhook inverse la consultation périodique : un service appelle un point d’accès lorsqu’un événement survient. Il faut vérifier l’expéditeur, gérer les nouvelles tentatives et les événements livrés plusieurs fois. Aucune méthode ne convient partout.

Sécurité et données privées

HTTPS protège les données pendant le transport si le certificat du serveur est vérifié. Authentifiez les appelants et autorisez séparément chaque opération et chaque objet. Un jeton valide ne donne accès qu’à sa portée ; il ne rend pas une entrée arbitraire sûre. Contrôlez taille et type des demandes, évitez de divulguer des données privées dans les erreurs et imposez des limites contre les abus.

Les secrets ne doivent pas apparaître dans des URL publiques, du code côté navigateur ou des journaux. Remplacez les identifiants exposés, réduisez leurs droits et séparez les accès de production et de test. Si une API accepte une URL de rappel, vérifiez sa destination pour empêcher l’accès à des réseaux internes. Documentez les données personnelles retournées.

Fiabilité et performance

Le réseau peut échouer : les clients ont besoin de délais d’attente, de nouvelles tentatives limitées et d’un traitement des échecs partiels. Relancer une lecture peut être sans risque ; relancer un paiement ou une autre modification exige un mécanisme d’idempotence contre les doublons. La pagination limite la taille des résultats. Le cache aide les données publiques stables, mais les réponses privées ou changeantes réclament une politique prudente.

Mesurez latence, erreurs et disponibilité depuis le parcours réel du client. Un code HTTP 200 peut contenir des données incomplètes ou inutilisables : surveillez aussi le résultat attendu. Les limites de débit protègent le service et doivent être annoncées clairement. Pour un service important, prévoyez une page d’état ou un canal d’assistance.

Concevoir ou choisir un service

Partez de la tâche de l’utilisateur et du contrat de données, puis choisissez un style que les clients peuvent utiliser et l’équipe maintenir. Testez succès, saisies invalides, identifiants expirés, droits, pagination et délais d’attente. Gardez les exemples à jour et montrez des erreurs concrètes. Avant d’intégrer un tiers, lisez ses limites d’usage, sa politique de données et ses annonces de changement : toute dépendance peut tomber.