QCM : Architectures logicielles avancées — 59 questions

Explication

Une page Web désigne généralement un contenu basique et statique, alors qu’une application Web est un logiciel accessible par Internet et souvent structuré selon une architecture client-serveur. Confondre les deux notions revient à ignorer la dimension logicielle et distribuée de l’application Web.

Explication

Le front-end est la partie graphique côté client qui reçoit directement les interactions de l’utilisateur. Le back-end fonctionne côté serveur et fournit des services, tandis que la base de données et l’API ne constituent pas l’interface graphique elle-même.

Explication

Le back-end est la partie serveur qui réalise des calculs et donne accès aux données pour le front-end. L’affichage graphique relève du front-end, tandis que le back-end ne remplace pas le protocole réseau.

Explication

REST, ou Representational State Transfer, est un style d’architecture reposant notamment sur la séparation client-serveur, l’absence d’état des commandes, la mise en cache et une interface uniforme. Le réduire à une bibliothèque Java ou à un protocole réseau constitue une confusion de nature.

Explication

REST s’appuie sur le protocole HTTP, tout en organisant son utilisation autour d’une ressource, d’une action, de données d’entrée et d’une réponse. HTTP n’est donc pas un style d’architecture, et REST ne constitue pas un protocole indépendant qui remplacerait HTTP.

Explication

Une ressource REST représente un objet du back-end, souvent matérialisé par une classe Java, et elle est repérée par une partie de l’URI. Un verbe HTTP décrit l’action d’une route, mais ne constitue pas à lui seul une ressource.

Explication

Une route REST est identifiée par le couple formé du verbe HTTP et de l’URI, et les noms des paramètres de chemin ne différencient pas ces deux modèles. En revanche, POST foo/bar et GET foo/bar ne sont pas en conflit, car leurs verbes diffèrent.

Explication

La classe de la ressource est annotée avec @RestController, tandis que @RequestMapping permet de définir l’URI correspondante. Inverser ces responsabilités constitue la confusion principale entre les deux annotations.

Explication

L’annotation indique une route GET dont le chemin est world et dont le type de réponse est du texte brut. Le paramètre produces ne transforme pas la route en POST, en DELETE ou en réponse HTML.

Explication

Une route POST reçoit généralement dans le corps la donnée destinée à être créée, alors qu’une route GET sert à récupérer des données en lecture seule. Le remplacement complet et la modification partielle relèvent plutôt des distinctions entre PUT et PATCH.

Explication

Avec PATCH, les attributs absents du JSON peuvent rester inchangés, ce qui convient à une modification partielle. PUT est théoriquement associé à la réception d’un objet complet destiné à remplacer l’objet ciblé, contrairement à l’idée d’une conservation partielle.

Explication

Le corps HTTP convient aux données complexes, comme les critères détaillés d’une recherche. L’URI est davantage adaptée aux données simples et à l’identification de ressources.

Explication

Toute requête REST reçoit une réponse HTTP, même si la méthode Java retourne void. Le retour void ne supprime donc pas la réponse ni ses éléments éventuels.

Explication

Le code 404 Not Found signale que la ressource demandée n’a pas été trouvée. Le code 400 concerne une requête incorrecte, tandis que 405 concerne une méthode non autorisée.

Explication

ResponseEntity et ResponseStatusException permettent d’associer l’erreur à un code HTTP adapté. Laisser toute erreur applicative devenir une erreur 500 fournit une information trop générale au client.

Explication

Un DTO représente les attributs nécessaires au transfert entre le back-end et le client, tout en pouvant exclure les données sensibles. Une entité complète risque au contraire d’exposer des attributs confidentiels.

Explication

Le UserDTO transfère name, address et id sans inclure pwd. Retourner directement User peut exposer cet attribut confidentiel dans la réponse.

Explication

Le marshalling transforme un objet en un format transmissible, par exemple un objet Java en JSON placé dans le body. La transformation inverse, du format transmis vers l’objet, est le démarshalling.

Explication

OpenAPI sert à décrire et modéliser l’API avant son implémentation, puis peut aider à générer un squelette de back-end et des tests. Spring Boot reste le framework chargé de l’implémentation.

Explication

Dans paths, une route est décrite par son URI, son verbe, ses paramètres éventuels, sa requête, ses réponses HTTP et le schéma du contenu. Les éléments liés à la base de données ne constituent pas la structure de cette description.

Explication

Une API CRUD organise des routes génériques autour de Create, Read, Update et Delete. Une API orientée application adapte ses routes aux besoins concrets du front-end, par exemple pour fournir une vue particulière.

Explication

L’annotation @Service identifie une classe dédiée à la logique ou à l’accès aux données, utilisable par injection. @Controller sert plutôt à gérer les routes HTTP et ne caractérise pas la couche de service.

Explication

Le service prend en charge la logique métier ou la gestion des données, tandis que le contrôleur s’occupe des routes. La déclaration des routes relève donc du contrôleur et non du service.

Explication

L’ORM assure la conversion entre les attributs des objets et les valeurs des tables relationnelles, dans les deux sens. Il ne remplace pas les classes par des procédures et ne concerne pas directement les requêtes HTTP.

Explication

@Entity indique que la classe doit être persistée et @Id désigne l’attribut servant de clé primaire. @GeneratedValue peut gérer la génération de cette clé, mais ne remplace pas l’annotation @Id.

Explication

@Id marque l’attribut qui sert de clé primaire pour l’entité. Le choix de la génération automatique de sa valeur relève plutôt de @GeneratedValue.

Explication

@GeneratedValue contrôle la génération automatique de la valeur d’un attribut identifiant. @EmbeddedId sert plutôt à représenter une clé composée dans un attribut intégrable.

Explication

La collection de Todo dans TodoList correspond à une relation un-à-plusieurs, déclarée avec @OneToMany(mappedBy = "list"). Chaque Todo possède la relation inverse plusieurs-à-un avec @ManyToOne.

Explication

SINGLE_TABLE regroupe les instances de la hiérarchie dans une seule table. TABLE_PER_CLASS crée une table par classe, tandis que JOINED répartit les colonnes entre des tables liées.

Explication

CrudRepository fournit les opérations de persistance pour un type d’objet identifié par un type de clé. Il ne constitue ni une classe métier, ni une entité, ni un contrôleur HTTP.

Explication

save, delete, findById et findAll correspondent respectivement à l’enregistrement, la suppression, la recherche par clé et la récupération de tous les objets. En particulier, findById vise une clé donnée alors que findAll parcourt l’ensemble.

Explication

L’annotation @Id indique au repository quel attribut représente l’identité de l’entité lors des opérations comme save et findById. Elle ne détermine ni la stratégie d’héritage, ni le type de résultat des requêtes, ni l’injection comme service.

Explication

Une entité devient persistante lorsqu’une opération telle que persist ou merge est appelée. L’annotation @Entity décrit la classe persistable, mais ne déclenche pas à elle seule la persistance.

Explication

MockMvc utilise mvc.perform pour exécuter la requête, andExpect pour contrôler le statut ou le contenu, et andDo peut afficher la réponse. andDo ne crée pas la requête et andExpect ne sert pas à l’exécuter.

Explication

Le test paramétré réutilise la même structure pour chacune des données produites par la méthode source. Des tests séparés reproduiraient cette structure au lieu de mutualiser son exécution.

Explication

Les tests REST couvrent notamment les cas nominaux, les entrées, les réponses, les requêtes malformées, les injections, l’authentification, la performance et la montée en charge. L’apparence des pages et l’organisation du code ne constituent pas le périmètre principal de cette liste.

Explication

permitAll permet l’accès aux routes publiques sans connexion, tandis qu'authenticated impose une authentification aux autres routes. Inverser ces règles protégerait les routes publiques et ouvrirait les routes privées.

Explication

JSESSIONID est l’identifiant confidentiel de session transmis dans un cookie et utilisé pour reconnaître l’utilisateur lors de l’accès privé. Le mot de passe sert à établir l’authentification, mais il n’est pas le rôle du JSESSIONID.

Explication

L’authentification crée ou récupère une session, dont l’identifiant JSESSIONID est renvoyé au client et réutilisé dans les requêtes privées. Le client ne fabrique pas normalement cet identifiant avant l’établissement de la session.

Explication

Les mots de passe doivent être envoyés dans le corps d’un POST via HTTPS et stockés sous forme de hash, par exemple avec bcrypt. Le stockage en clair ou l’utilisation d’un transport non chiffré expose directement les identifiants.

Explication

Le contrôle d’accès récupère l’identité via Principal, transmet son login au service et vérifie la propriété de l’objet demandé. Une session valide prouve l’authentification, mais elle ne démontre pas que la commande appartient à cet utilisateur.

Explication

API1 apparaît lorsque le serveur contrôle l’existence de l’objet mais pas son appartenance à l’utilisateur demandeur. Les autres situations relèvent respectivement des propriétés d’objet, de l’authentification et de la consommation de ressources.

Explication

API2 concerne l’absence ou la faiblesse de l’authentification ; l’endpoint doit donc exiger une session valide et retourner 401 sans elle. Le code 403 et l’exigence d’un rôle concernent plutôt une restriction d’autorisation déjà authentifiée.

Explication

Un DTO contrôlé permet de définir précisément les propriétés que le client peut modifier et de refuser les autres. La présence d’une session ou l’existence de l’objet ne contrôle pas les champs autorisés.

Explication

API6 concerne l’automatisation massive d’un processus métier sensible, même lorsque l’accès est correctement authentifié. Une réponse non chiffrée relève d’un autre type de faiblesse et ne définit pas ce risque.

Explication

La prévention de SSRF repose sur une liste de destinations autorisées et sur le blocage des cibles internes pour les URL fournies par le client. Une URL fournie par le client reste une entrée non fiable, même si sa syntaxe est correcte.

Explication

API10 se corrige en contrôlant la structure et le contenu des données externes à l’aide de DTO et de contraintes de validation. L’identité du serveur distant ne garantit pas que les données reçues respectent le format ou les valeurs attendus.

Explication

API9 désigne une gestion défaillante de l’inventaire des endpoints et des versions d’API. La validation des valeurs concerne plutôt la consommation sûre des données externes, notamment dans API10.

Explication

La gestion du cycle de vie commence par l’inventaire des endpoints et des versions, se poursuit par une politique de dépréciation, puis aboutit à la suppression des versions inutiles. La dépréciation annonce et planifie une fin de vie, tandis que la suppression retire effectivement la version.

Explication

Une API oubliée peut rester accessible et présenter des faiblesses sans bénéficier d’un suivi ou de protections à jour, ce qui accroît la surface d’attaque. Une version ancienne non surveillée ne bénéficie pas automatiquement de contrôles plus stricts.

Explication

Cette vulnérabilité apparaît lorsque le back-end fait confiance aux données externes sans vérifier leur structure et leur contenu, alors que leur format peut changer. Le chiffrement protège la confidentialité, mais ne remplace pas la validation des données reçues.

Explication

Les données externes doivent être vérifiées à la fois sur leur format et sur leurs valeurs avant leur utilisation par le back-end. Contrôler seulement la provenance ou la longueur ne permet pas de détecter toutes les structures et valeurs invalides.

Explication

L’annotation @Valid déclenche l’évaluation des contraintes de validation présentes dans le DTO. @Validated sert notamment à sélectionner certains groupes de contraintes, ce qui répond à un besoin différent.

Explication

Une contrainte non respectée interrompt l’exécution de la méthode et entraîne une réponse 400 Bad Request. Le code 201 correspond à la création d’une ressource, tandis que 204 signale une réussite sans contenu.

Explication

@Pattern vérifie qu’une valeur correspond à un motif défini, généralement une expression régulière. @Past concerne une date antérieure, @Positive une valeur numérique et @NotEmpty l’absence de chaîne ou collection vide.

Explication

PUT remplace la représentation complète d’une ressource et produit le même état final lorsqu’une même requête est répétée. PATCH sert plutôt à une modification partielle, tandis que POST est généralement utilisé pour créer une nouvelle ressource.

Explication

Cette URI utilise le nom pluriel de la collection et réserve les paramètres de requête au filtrage. Les autres formes introduisent des verbes ou encodent l’action directement dans le chemin.

Explication

Le statut 401 indique que le client doit fournir une authentification valide. Le statut 403 signifie que l’accès est interdit malgré une requête identifiée ou comprise, tandis que 404 signale une ressource introuvable.

Explication

Le versioning par header peut utiliser l’en-tête Accept pour demander la représentation correspondant à la version 1. Le chemin /v1/users place la version dans l’URI, tandis que ?version=1 la place dans les paramètres de requête.