Développement Logiciel / Bonnes pratiques Flashcards

1
Q

Selon clean code, quel est le principe d’un commentaire ?

A

Expliquer des choses que le code ne peut peut pas exprimer de lui même.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Selon clean code, que faut t’il éviter dans un commentaire ?

A

Les données déjà save par git (date, auteur…), mal rédigés, le code mis en commentaire .

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Selon clean code, quelles sont les bonnes pratiques au niveau des arguments de fonction ?

A

Le moins possible, pas d’arguments de sortie, les arguments booléens

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Que faire avec un test qui ne passe pas ?

A

Ne pas le supprimer, mais plutôt le réparer.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Que doit faire une fonction ?

A

Exactement ce qu’on attend d’elle, ne pas qu’elle ai un comportement caché, sinon on n’aura plus confiance dans le code.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Qu’est ce que la redondance selon clean code ?

A

Le mal

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Fonction et abstraction selon clean code ?

A

Une fonction doit avec son propre niveau d’abstraction. Il ne faut pas mélanger bas niveau et haut niveau.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Classe mère et classe fille selon clean code ?

A

La classe mère ne doit pas connaitre les classes filles.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Que doit on faire avec le code mort ?

A

Le supprimer, de toute façon il est save avec Git.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Qu’est ce que la séparation verticale (clean code) ?

A

Le code doit se rapprocher le plus possible au niveau vertical des méthodes qu’il appelle, pour ne pas devoir scroller pendant des heures.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Quel est l’ordre des opérations en informatique ?

A

Dans le même ordre qu’en mathématique.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Qu’est ce que l’incohérence dans Clean Code ?

A

Le fait de toujours faire une chose de la même manière dans le code, sauf à des endroits sans aucune justification

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Qu’est ce que le désordre dans Clean Code ?

A

Le fait de mal ranger ses fichiers et dossiers

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Qu’est ce que les variables explicatives ?

A

Le fait de stocker des résultats intermédiaires pour rendre plus lisible l’intention de l’algorithme

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Est-ce une bonne idée de faire un nom de fonction long ?

A

Oui, si on ne peut pas rendre clair le rôle de la fonction avec un nom court.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Que faut t’il préférer au switch / if else ?

A

Le polymorphisme.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Qu’est ce qu’un nombre magique ?

A

C’est un nombre qui n’a pas variable associée, qui est juste posée comme ça dans le code. C’est une erreur quand on veut comprendre le code, ou faire du refactoring.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Qu’est ce que doivent faire une fonction ?

A

Une seule chose.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Que faut t’il éviter avec les fonctions booléens ?

A

Pas de négatif, c’est à dire pas de “Not” dans le nom.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Comment bien choisir un nom de fonction ?

A

Clair sur son rôle, et clair sur son niveau d’abstraction.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Que faut t’il éviter au niveau de la codification des noms de variable ?

A

Le hungarian case par exemple, qui consiste à préciser le type de la variable : name_s, age_i.. C’est pas beau. Il faut aussi éviter le mot list, ou object dans le nom des variable. Pour list, mieux vaut préférer le s du pluriel.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Qu’est il nécessaire lors des tests unitaire selon clean code ?

A

Qu’il teste assez de chose, qu’ils soient rapide à executer et qu’il y ai un outil de couverture de code.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Est il possible d’atteindre des tests exhaustifs ?

A

Non

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Pourquoi il vaut mieux tester le plus tôt possible ?

A

Pour éviter les problèmes en prod, et donc perdre de l’argent

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Comment sont placés les bugs ?

A

Ils sont souvent regroupés entre eux. Donc si il y a un problème quelque part, c’est bien de chercher d’autres bugs autour aussi

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Si le produit est mal conçu, à quoi sert de corriger les bugs ?

A

A rien, puisque les specs sont mauvaises

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Que faut il faire au niveau des tests avec les fonctionnalités critiques ?

A

Rajouter beaucoup de tests unitaires

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Ou mène le mauvais code ?

A

Vers la faillite : réduit la productivité, l’ajout de features, la maintenance et le turnover

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Est ce que la remise à Zero (refaire app) est une bonne chose ?

A

ça peut l’être si le code est vraiment dégeux. Par contre, si y’a pas de bonnes pratiques, alors on repart pour du code degeux.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Comment lutter contre la pression du patron qui veut accélèrer, quitte à faire du code dégeux ?

A

C’est dans son intérêt, métaphore avec le batiment (fondations sont pourries), et on est les seuls à connaître le code, il faut le protéger.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Selon Clean code, que sont les développeurs ?

A

Des artistes.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Qu’est ce qu’un code propre ?

A

Fait pour être lu, élégant, simple et direct, pas redondant et compris par les autres, avec des niveaux d’abstractions.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Quelles sont les règles de Dijkstra dans le clean code ?

A

Un seul return, pas de break ou de continue, jamais de goto

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

Comment rendre les constructeurs plus clairs ?

A

On peut faire des constructeurs statiques, pour ajouter un nom au constructeur.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

Comment faire une bonne séparation verticale ?

A

Doit être lu comme un journal, le titre en haut, les notions clés ensuite, puis les détails. On assemble les mêmes idées entre elles.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

Comment faire une bonne mise en forme horizontale ?

A

Mettre un espace entre les opérations, limite de longueur, ne pas rompre l’identation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

Quel est le principe du singleton ?

A

Une seule instance d’une classe dans tout le code

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

Comment mettre en place un singleton ?

A

Une classe, avec un constructeur private et une méthode statique qui voit instancier ou retourner notre singleton

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

Quand mettre en place le singleton ?

A

1 : On veut un seul et unique object, avec les mêmes paramètres, pour tous les utilisateurs. 2 : On veut accéder facilement à l’object, sans le passer via des paramètres ou des variables globales.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

Quels sont les avantages du singleton ?

A

On garantie l’unicité de l’instance, Point d’accès global, sans variables globales

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Quels sont les inconvénients du singleton ?

A

Ne respecte pas SOLID, convient mal avec le multithreading, les tests unitaires deviennent compliqués.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

Quel est le principe de la Fabrique (Factory) ?

A

Remplace les appels directs des constructeurs des objets par une classe qui gère la logique de construction.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

Comment mettre en place une Factory ?

A

Créer une classe Factory, avec la logique de construction dedans. Supprimer les appels directs des constructeurs d’objets.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

Quand mettre en place la Factory ?

A

Quand on a trop de logique dans les constructeurs, ou dans le choix des objets à instancier. Sert à éviter les gros if else / switch case, et d’isoler la logique de construction.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q

Quels sont les avantages de la Factory ?

A

Responsabilité unique : déporter la logique de construction. Ouvert/fermé : Permet de construire de nouveaux objets facilement.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q

Quel est le principe de l’Abstract Factory ?

A

Une factory, mais avec des classes filles Factory, tout simplement.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

Quel est le principe du Builder Pattern ?

A

On ajoute des classes intermédiaires, qui vont nous servir pour définir les valeurs des attributs / valeurs du constructeurs. Pour une classe Computer, on va donc définir un GamingComputerBuilder, un DeskComputerBuilder, un LaptopComputerBuilder… Tout en construisant toujours un object de type Computer

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q

Quand utiliser le Builder Pattern ?

A
  1. Quand on a beaucoup d’arguments dans un constructeur. 2. Quand on a beaucoup de variations dans les paramètres du constructeur, mais peu de variation dans la logique des objets (sinon on ferait directement des classes filles)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q

Quels sont les avantages du Builder Pattern ?

A

On évite les créations d’objet via le constructeur qui ne veulent rien dire. On découpe le code de construction du métier. On peut réutiliser le même code de construction pour d’autres objets.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q

Quels sont les inconvénients du Builder Pattern ?

A

Nécessite beaucoup de classes. Si il y a de la logique métier pour les différents objets construits par le Builder, autant faire des classes filles avec une Factory.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
51
Q

Quel est le principe du Prototype ?

A

On définit une méthode clone pour les objets, pour copier un objet sans avoir besoin d’appeler un constructeur.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
52
Q

Quand utiliser le Prototype ?

A

Quand les objets sont une galère à créer (constructeurs d’une lib qui prend trop de paramètres, ou trop flou)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
53
Q

Quels sont les avantages du Prototype ?

A

Cloner des objets sans faire toutes l’initialisation, et donc retirer du code redondant, Créer des objets complexes facilement en copiant

54
Q

Quels sont les inconvénients du Prototype ?

A

Les relations entre objets, surtout circulaires, deviennent presque impossible à gérer (il faut cloner, puis cloner, mais recloner après ?)

55
Q

Quel est le principe de l’Adaptateur ?

A

On va adapter une classe à une interface, sans modifier la classe.

56
Q

Comment mettre en place l’Adaptateur ?

A

Imaginons une classe d’une librairie. Elle n’implémente pas une interface souhaitée. On va venir l’enrober (ou faire une classe fille), qui va implémenter les fonctions de l’interface souhaitée.

57
Q

Quand utiliser l’Adaptateur ?

A

Quand on ne peut pas modifier une classe, mais qu’on veut implémenter une interface dedans

58
Q

Quel est le principe du Pont ?

A

On découpe notre objets en petits objets implémentant une interface. ça permet d’être beaucoup plus flexible dans l’utilisation de notre objet.

59
Q

Comment mettre en place le Pont ?

A

Diviser les responsabilités d’une classe, les découper en sous-classes. Implémenter une interface pour ces sous-classes. Donner la possibilité, par exemple dans le constructeur, de pouvoir choisir l’objet à utiliser. (exemple, donner un objet pour choisir le display)

60
Q

Quand utiliser le Pont ?

A
  1. Quand on souhaiter diviser une classe trop monolithique. 2. Si on veut avoir une logique abstraite, non dépendante du type d’objet
61
Q

Quel est le principe du Composite ?

A

Quand on a une structure en arborescence, implémenter une même interface, autant pour les branches que pour les feuilles.

62
Q

Quand utiliser le Composite ?

A

Quand on a une structure en arborescence, et qu’on veut la parcourir, sans checker à chaque fois le type d’objet.

63
Q

Quel est l’inconvénient de Composite ?

A

Il peut être compliqué de trouver des interfaces communes, ou alors on les rend trop génériques, les rendant impossible à comprendre.

64
Q

Quel est le principe du Décorateur ?

A

On va enrober une propriété, une méthode, un constructeur… d’un comportement, avant ou après.

65
Q

Quand utiliser le Décorateur ?

A

On veut étendre des comportements seulement au moment de l’exécution, sans alterer le code source des objets. (donc par exemple un décorateur d’un framework), ou si l’héritage est impossible ou n’a pas de sens.

66
Q

Quels sont les avantages du Décorateur ?

A

Etendre le comportement de l’objet sans avoir besoin de créer une nouvelle sous-classe, ajouter ou retirer dynamiquement des responsabilités à un objet au moment de l’exécution, combiner plusieurs comportements en emballant plusieurs décorateurs…

67
Q

Quels sont les inconvénients du Décorateur ?

A

Retirer un décorateur n’est pas facile, pas facile de mettre un décorateur qui ne dépend pas de sa position, code de configuration des couches de décorateur peut être moche.

68
Q

Quel est le principe d’une Facade ?

A

Cacher le code complexe pour offrir un point d’accès simple à une feature. On utilise souvent une classe statique pour ça. La façade doit gérer tout le cycle de vie des sous systèmes…

69
Q

Quand utiliser une Facade ?

A

Quand on veut simplifier l’utilisation d’une API. Quand on a besoin d’une sous partie d’une API complexe. Quand on veut structurer un sous systèmes en plusieurs couches.

70
Q

Quel est l’avantage d’une Facade ?

A

On simplifie un sous-sytème complexe.

71
Q

Quels sont les inconvénients d’une Facade ?

A

Peut devenir un objet omniscient. Si c’est le cas, il faut diviser en sous Facades.

72
Q

Quel est le principe du Proxy ?

A

On ajoute une couche autour d’un service, ce qui va nous permettre d’ajouter un comportement. Service de log, de cache, d’authentification… C’est un peu un middleware.

73
Q

Quand utiliser le Proxy ?

A

Authentification, logs, lancement d’un service distant, mise en cache, gestion d’erreur…

74
Q

Quels sont les avantages du Proxy ?

A

Controller le service sans toucher au code source, gérer le cycle de vie du service…

75
Q

Quel est le principe du poids mouche ?

A

On va faire partager des données communes aux objets, pour éviter la redondance et donc la RAM.

76
Q

Quand utiliser le poids mouche ?

A

Quand un programme génère trop d’objets, donc consomme trop de ressources (exemple avec des balles). Quand les objets contiennent des états identiques qui peuvent être partagés.

77
Q

Quels sont les avantages du poids mouche ?

A

Economise beaucoup de RAM si il y a des tonnes d’objets similaires

78
Q

Quels sont les inconvénients du poids mouche ?

A

Le code peut devenir très moche !

79
Q

Quel est le principe de la Chaîne de responsabilité ?

A

On va construire des étapes, indépendantes des autres, puis on va construire un objet qui va nous permettre de définir l’ordre.

80
Q

Quand utiliser la chaîne de responsabilité ?

A

Quand l’ordre varie durant l’execution (donc on peut pas l’hardcoder), ou quand l’ordre n’est pas connu à l’avance.

81
Q

Quels sont les avantages de la chaine de responsabilité ?

A

On peut facilement ajouter un maillon, on peut définir lors du runtime l’ordre des étapes.

82
Q

Quel est le principe du design pattern Commande ?

A

On sépare l’objet qui lance l’action (par exemple un bouton) de l’action en elle même. C’est le principe des événements dans Javascript.

83
Q

Quand utiliser le design pattern Commande ?

A

Surtout dans le front, quand on veut créer des objets visuels, mais y associer une logique par dessus, sans devoir recréer des sous-classes.

84
Q

Quels sont les avantages du design pattern Commande ?

A

On sépare le rendu visuel du traitement, on peut combiner facilement plusieurs traitement.

85
Q

Quel est le principe du Mémento ?

A

On veut faire des sauvegardes d’un objet, pour pouvoir changer rapidement de version quand il le veut. On va implémenter 3 objets : la cible, le mémento (données sauvegardées), et le gardien, qui va créer des mémento et les charger)

86
Q

Quand utiliser le Mémento ?

A

On veut implémenter une sauvegarde, ex avec un control Z, ou quand on veut sécuriser les données d’un objet.

87
Q

Quels sont les avantages du Mémento ?

A

Simplifie le code de l’objet en laissant le gardien s’occupe de la sauvegarde et du rechargement.

88
Q

Quels sont les inconvénients du Mémento ?

A

Si trop de snapshot, alors trop de RAM consumée. Il faut gérer les mémento trop anciens.

89
Q

Quel est le principe de l’Observateur ?

A

On veut créer un watcher, de sorte que le diffuseur n’ai pas besoin d’hardcoder les abonnés (ceux qui écoutent). Ce sont plutôt les abonnés qui vont s’ajouter tous seuls.

90
Q

Quand utiliser l’Observateur ?

A

Quand le nombre d’abonnés n’est pas connu à l’avance, ou que c’est variable dans le temps

91
Q

Quels sont les avantages de l’Observateur ?

A

On peut facilement ajouter un nouvel abonné.

92
Q

Quels sont les inconvénients de l’Observateur ?

A

Les abonnés sont avertis dans un ordre aléatoire.

93
Q

Quel est le principe du design pattern Etat ?

A

Imaginons un hero, qui peut être empoisonné, blessé, brulé… Son comportement va être à chaque fois modifié. L’Etat va créer une sous classe pour chaque comportement, qui spécifier quel comportement adopter.

94
Q

Quand utiliser le design pattern Etat ?

A

Quand un objet varie en fonction de son état, et qu’il y a beaucoup d’états. Si il est trop pollué par des blocs conditionnels, et trop de code dupliqué dans les états

95
Q

Quel est l’avantage du design pattern Etat ?

A

Un état = une classe, donc responsabilité unique, ouvert/fermé, simplifie le code du contexte

96
Q

Quel est l’inconvénient du design pattern Etat ?

A

Exagéré si peu d’états ou peu de transitions.

97
Q

Quel est le principe du Visiteur ?

A

On va séparer les classes de données et les algorithmes.

98
Q

Quelles sont les questions à se poser avant de faire des logs ?

A

Est ce que ce log est vraiment utile ? Est-ce que cette info n’existe pas déjà ailleurs ? Est ce que je vais log un gros objet ? Si oui, est ce que je peux logger seulement quelques infos de l’objet ? Est ce que l’info que je log va m’aider à debugger / comprendre le process ?

99
Q

Quels sont les 4 niveaux de logs ?

A

ERROR, WARNING, INFO, DEBUG

100
Q

Pourquoi les logs peuvent couter chers ?

A

Parce qu’ils prennent beacoup d’espace sur le disque

101
Q

Que faut t’il avoir sur des logs ?

A

Le même pattern, pour pouvoir facilement les scrapper par la suite.

102
Q

Que veut dire AOP ?

A

Aspect Oriented Programmation.

103
Q

Quel est le principe de l’AOP ?

A

On sépare clairement le détails techniques du code. C’est à dire que l’on va cacher le principe de cache, de logs… pour rendre le code métier très simple et très clair.

104
Q

Quels sont les 3 concepts de l’AOP ?

A

Le joint point (avant ou après la méthode ?), le point cut (Quelles méthodes ? Via une regex ?), l’aspect (quoi faire ?)

105
Q

Que peut on mettre dans les aspects en AOP ?

A

Des logs, du cache, des transaction, des timers…

106
Q

Comment développer facilement sur une machine distante ?

A

Avec l’extension remote dev sur VScode, en SSH

107
Q

Qu’est ce que Mermaid JS ?

A

Un package qui permet de construire à partir d’un texte des diagrammes SVG

108
Q

Quels sont les avantages de Mermaid JS ?

A

Plus besoin de glisser déposer les éléments, tout est en code, On peut versionner plus facilement, Les modifications sont BEAUCOUP, BEAUCOUP plus simples, On se prend plus la tête à relier les éléments à la main, Le bonus, il est intégrable avec docusaurus directement !

109
Q

Quel est la bonne pratique avant de commencer un diagramme (quel outil utiliser) ?

A

Il faut regarder Mermaid JS avant de se lancer, pour voir si le diagramme que l’on souhaite faire est adapté. Sinon on peut se pencher du côté de D2.

110
Q

Qu’est ce que D2 ?

A

Un langage de diagramme, comme Mermaid JS.

111
Q

Comment les rayons cosmiques peuvent créer un bug ?

A

En modifiant les bits, et donc créer un bug.

112
Q

Qu’est ce que gitmoji ?

A

Une convention de nommage des intentions des commits, en utilisant des emojis.

113
Q

Quand utiliser les git subtree ?

A

Quand on veut inclure un autre répo dans notre répo. (pas en copiant collant hein)

114
Q

Qu’est ce que gitsubtree ?

A

Fonctionnalité git qui permet d’ajouter un répo à un autre.

115
Q

Que signifie le S de SOLID ?

A

Single Responsabilité : une classe ne doit avoir qu’un seul objectif métier ou technique

116
Q

Que signifie le O de SOLID ?

A

Open Close : Créer des classes filles à la place de if instanceof, pour abstraire le code.

117
Q

Que signifie le L de SOLID ?

A

Liskov Substitution : L’ajout d’une classe fille ne doit pas casser l’abstraction utilisant la classe mère.

118
Q

Que signifie le I de SOLID ?

A

Interface Segregation : On divise en petites interface les objets qui dépendent d’une grosse interface. Qui peut le plus peut le moins.

119
Q

Que signifie le D de SOLID ?

A

Dependency : Il vaut mieux utiliser une interface (ou classe abstraite) plutôt qu’une classe fille, ou une classe en dur.

120
Q

Pourquoi le singleton est dangereux (antipattern) ?

A

C’est un goulot d’étranglement, car pleins d’utilisateurs dessus en même temps, les tests unitaires deviennent compliqués et le multithreading peut poser problème.

121
Q

Pourquoi Null n’est pas aimé par certains développeurs ?

A

Car il peut remprésenter plusieurs choses (absent, incomplet, invalide…). Et qu’il n’est pas polymorphique (donc on est obligé d’ajouter des blocs if.)

122
Q

Quelles sont les 7 principes de REST ?

A

Les URL pour faire le routage, les méthodes HTTP portent des informations, mise en cache possible, stateless, archi en couches, ajout de code à la demande, peut préciser le type de réponse voulu.

123
Q

POST vs PULL vs PATCH ?

A

PUT décrit toute la ressource, créé si elle n’existe pas ou l’écrase. PUT est idempotent (même résultat à chaque fois). PATCH c’est comme PUT, mais pas obligé de décrire toute la ressource. POST peut définir aussi bien la création d’une ressource qu’une action à effectuer.

124
Q

Que signifie le code de retour 201 en HTTP ?

A

Resource créée

125
Q

Que signifie le code de retour 204 en HTTP ?

A

Ok mais pas de body

126
Q

Que signifie le code de retour 204 en HTTP ?

A

Ok mais pas de body

127
Q

A quoi sert le versioning d’une API ?

A

A pouvoir s’assurer que les clients qui tapaient dans les anciens schémas n’aient pas besoin de modifier leur code pour que ça marche encore. Et pour les devs, c’est de pouvoir s’assurer qu’on puisse modifier l’API sans impacter les clients.

128
Q

Quelles sont les 5 méthodes pour gérer le versioning d’API ?

A

Aucun contrôle de version, Mettre la version dans l’URL, mettre la version en tant que paramètre dans l’URL, Mettre la version dans un header personnalisé, Mettre la version dans le Content-Type

129
Q

Que faire si une version est trop vieille, qu’elle ne correspond plus au besoin métier ?

A

On peut la déclarer comme dépréciée, et donc rediriger avec une 301 l’api. Oblige donc le client a changer son code.

130
Q

Qu’est ce que l’HATEOAS ?

A

Une technique d’autodocumentation de notre API : on va renvoyer dans le body de le ressource toutes les actions possibles, à travers quels URL et quelles méthodes HTTP utiliser. (on peut aussi préciser le schéma). Cela permet une navigation plus fluide pour le client.