Le choix entre une API (qui renvoie des données JSON) et un site qui génère des pages HTML dépend de l'ARCHITECTURE de votre application et de qui/quoi consomme votre back-end — voici quand et pourquoi construire une API. Rappel de la différence : (1) Un site « classique » (SSR — génération de pages HTML côté serveur, comme on l'a vu) : le serveur PHP génère des PAGES HTML complètes envoyées au navigateur. Le back-end et le front-end sont couplés (le PHP produit l'affichage). (2) Une API : le serveur PHP expose des DONNÉES (JSON), pas des pages. Un client SÉPARÉ (application front-end JavaScript, application mobile, autre service) consomme ces données et gère l'affichage/l'usage. Le back-end (API) et le front-end sont DÉCOUPLÉS. Quand construire une API : (1) Application front-end séparée (SPA). Si votre interface est une « Single Page Application » (React, Vue, Angular…) qui gère l'affichage côté navigateur de façon dynamique et interactive, elle a besoin de DONNÉES (pas de pages HTML). Votre PHP expose alors une API JSON que le front consomme. C'est une architecture très répandue pour les applications interactives modernes (tableaux de bord, applications web « app-like »). (2) Application MOBILE. Une application mobile (iOS, Android) ne peut pas consommer des pages HTML — elle a besoin de DONNÉES (JSON) via une API. Si votre projet a (ou aura) une application mobile, une API est nécessaire. (3) Plusieurs clients / réutilisation du back-end. Point fort des API : UNE MÊME API peut servir PLUSIEURS clients — le site web, l'application mobile, des partenaires, d'autres services. Le back-end (logique, données) est CENTRALISÉ et RÉUTILISÉ. Si vous prévoyez plusieurs interfaces (web + mobile) ou d'exposer vos données à des tiers, une API est la bonne architecture. (4) Architecture de services / microservices. Dans des architectures où des services communiquent entre eux, les API sont le moyen d'échange. (5) Découplage front/back. Séparer le front (interface) et le back (API) permet à des équipes différentes (spécialistes front, spécialistes back) de travailler indépendamment, avec des technologies adaptées à chaque côté. Quand un site HTML « classique » (SSR) suffit : (1) Sites de CONTENU / interfaces simples : blogs, sites vitrines, sites d'information, applications peu interactives — générer des pages HTML côté serveur est plus simple et suffit (pas besoin d'un front séparé). (2) SEO prioritaire : les pages HTML générées côté serveur sont bien indexées (le SSR a un avantage SEO « out of the box », même si cela a évolué). (3) Un seul client (le site web), pas de mobile ni de tiers : le SSR est plus direct. (4) SIMPLICITÉ : pour une application pas très interactive, le SSR évite la complexité d'un front séparé + API. Les approches HYBRIDES : (1) Beaucoup d'applications combinent : des pages HTML (SSR) pour certaines parties, et des API pour les fonctionnalités dynamiques (le front fait des appels API en JavaScript pour mettre à jour sans recharger). (2) Les frameworks front modernes (avec SSR, comme Next.js/Nuxt côté JavaScript) combinent rendu serveur et interactivité. (3) On peut avoir un site PHP classique qui expose AUSSI une API (pour une application mobile, par exemple). Le choix pour votre PHP : (1) Si vous construisez une application avec un front SÉPARÉ (React/Vue) ou MOBILE, ou plusieurs clients → construisez une API (JSON). (2) Si vous construisez un site de contenu / interface simple avec un seul client (le web) → un site HTML classique (SSR) suffit. (3) Souvent, on combine (pages HTML + endpoints API pour le dynamique). Ce que cela signifie pour vos compétences : (1) Le BACK-END PHP que vous apprenez (logique, base, sécurité, authentification) est PERTINENT dans les deux cas — que vous génériez du HTML ou du JSON, la logique métier, l'accès aux données et la sécurité sont similaires. C'est surtout ce que PHP RENVOIE qui change (HTML vs JSON). (2) Savoir construire une API REST sécurisée est une compétence de plus en plus DEMANDÉE (car les architectures modernes séparent souvent back-end API et front/mobile). (3) Les frameworks (Laravel, Symfony) gèrent très bien LES DEUX (générer du HTML avec Blade/Twig, ET exposer des API JSON) — un même framework couvre les deux besoins. En résumé : construisez une API (données JSON) quand votre back-end est consommé par un FRONT SÉPARÉ (SPA React/Vue), une application MOBILE, ou PLUSIEURS clients/services (réutilisation, découplage) — l'architecture des applications interactives modernes. Construisez un site HTML classique (SSR) pour les sites de contenu / interfaces simples avec un seul client web (plus simple, bon pour le SEO). Souvent, on combine. Le choix dépend de qui consomme votre back-end (un navigateur affichant des pages, ou des clients variés voulant des données). Votre compétence back-end PHP (logique, données, sécurité) sert dans les deux cas ; savoir exposer une API REST sécurisée est un atout croissant pour les architectures modernes. Les frameworks PHP gèrent très bien HTML et API — vous choisirez selon l'architecture de chaque projet.

Les JWT (et l'authentification par jetons en général) sont très utilisés pour les API parce qu'ils conviennent mieux à leur nature (sans état, clients variés) que les sessions classiques — comprendre le mécanisme et le pourquoi éclaire l'authentification d'API. Rappel du problème : HTTP est SANS ÉTAT (chaque requête indépendante). Pour qu'une API « sache » quel utilisateur fait une requête (après connexion), il faut un mécanisme d'authentification qui accompagne chaque requête. Deux approches : les sessions (classiques) et les jetons (comme JWT). Les SESSIONS classiques (rappel) : après connexion, le serveur crée une SESSION (données côté serveur) et envoie un cookie d'identifiant ; à chaque requête, le navigateur renvoie ce cookie, le serveur retrouve la session. Cela fonctionne bien pour un site web classique (navigateur + cookies). Mais pour une API, les sessions posent des soucis : (1) elles reposent sur les COOKIES (gérés automatiquement par les navigateurs, mais moins naturels pour une application mobile ou un autre service qui consomme l'API) ; (2) elles nécessitent un STOCKAGE côté serveur (l'état des sessions) — ce qui complique la mise à l'échelle (plusieurs serveurs doivent partager les sessions) ; (3) elles sont liées au navigateur/domaine (moins adaptées aux clients variés). Les JETONS (JWT) : (1) Le mécanisme. Après une connexion réussie (le serveur vérifie identifiant + mot de passe), le serveur ÉMET un JETON — pour un JWT, un jeton SIGNÉ cryptographiquement contenant des informations (par exemple l'identifiant de l'utilisateur), signé avec une clé secrète du serveur. Le client REÇOIT ce jeton et le STOCKE (côté client). À CHAQUE requête suivante, le client ENVOIE le jeton (généralement dans l'en-tête HTTP Authorization: Bearer <jeton>). Le serveur VÉRIFIE le jeton (il vérifie la signature avec sa clé secrète — si la signature est valide, le jeton est authentique et non falsifié) et en extrait l'identité de l'utilisateur. (2) « Auto-porteur » (self-contained). Le JWT contient les informations nécessaires (l'identité) et est signé — le serveur peut le VÉRIFIER sans avoir à stocker de session côté serveur (il vérifie juste la signature). C'est SANS ÉTAT côté serveur : le serveur n'a pas besoin de « se souvenir » de quoi que ce soit, le jeton porte l'information. Pourquoi les JETONS conviennent mieux aux API : (1) SANS ÉTAT (stateless). Le serveur n'a pas à stocker de session — il vérifie le jeton à la volée. Cela simplifie la MISE À L'ÉCHELLE (n'importe quel serveur peut vérifier le jeton, sans partage de sessions — idéal pour plusieurs serveurs derrière un répartiteur de charge). (2) Adapté aux CLIENTS VARIÉS. Un jeton (dans un en-tête) est facile à utiliser pour TOUT client : une application mobile, un front JavaScript, un autre service — pas besoin de la gestion de cookies liée au navigateur. Les API sont souvent consommées par des clients non-navigateurs (mobile, services), où les jetons sont plus naturels. (3) DÉCOUPLAGE. Le jeton est autonome, réutilisable entre services, adapté aux architectures découplées (back-end API + front/mobile séparés). (4) FLEXIBILITÉ. Le jeton peut contenir des informations (identité, rôles) et être utilisé par plusieurs services. Les points de sécurité des JWT/jetons (importants) : (1) HTTPS OBLIGATOIRE. Les jetons circulent à chaque requête — sans HTTPS, ils pourraient être interceptés (et un jeton volé = accès usurpé). HTTPS est indispensable. (2) Stockage sûr côté client : le jeton doit être stocké de façon sûre côté client (attention au stockage exposé au XSS). (3) Expiration. Les jetons doivent EXPIRER (durée de vie limitée) pour limiter les dégâts si un jeton est compromis ; on gère souvent un mécanisme de « rafraîchissement » (refresh token). (4) Révocation. Un défaut des JWT auto-porteurs : ils sont difficiles à RÉVOQUER avant expiration (le serveur ne stocke pas d'état) — des stratégies existent (listes de révocation, durées courtes + refresh). (5) Ne pas mettre de données sensibles dans le JWT (son contenu est lisible, même s'il est signé — la signature garantit l'intégrité, pas la confidentialité du contenu). (6) Clé secrète bien protégée (elle signe/vérifie les jetons). Les frameworks et l'authentification d'API : les frameworks (Laravel avec ses outils d'authentification d'API, Symfony) fournissent des systèmes d'authentification d'API robustes (jetons, JWT, OAuth) qui gèrent ces subtilités correctement — en production, privilégiez ces solutions éprouvées plutôt que d'implémenter les JWT entièrement à la main (facile de faire des erreurs de sécurité). D'autres approches existent (jetons d'API simples stockés en base, OAuth pour l'accès délégué à des tiers) — le choix dépend du contexte. En résumé : un JWT est un jeton SIGNÉ cryptographiquement, auto-porteur (contient l'identité, vérifiable sans stockage serveur), émis à la connexion et renvoyé à chaque requête (en-tête Authorization) pour authentifier. On utilise des jetons (JWT) plutôt que des sessions pour les API car ils sont SANS ÉTAT (simplifient la mise à l'échelle — pas de sessions à partager), adaptés aux CLIENTS VARIÉS (mobile, front séparé, services — plus naturels que les cookies de navigateur), et DÉCOUPLÉS (architectures modernes). Points de sécurité : HTTPS obligatoire, expiration des jetons, stockage sûr, gestion de la révocation, clé secrète protégée. En production, utilisez les systèmes d'auth d'API éprouvés des frameworks. L'authentification par jetons est le standard pour les API modernes (front séparé, mobile) — une compétence clé pour le développement d'applications découplées, où le back-end PHP expose une API sécurisée consommée par des clients variés.