Architecture

Question 1

Quelle est la différence entre SOAP et REST ?

Answer 1

SOAP et REST sont deux approches différentes de la conception d’API. L’approche SOAP est hautement structurée et utilise le format de données XML. REST est plus flexible et permet aux applications d’échanger des données dans plusieurs formats.

SOAP est un protocole, tandis que REST est un style architectural. Cela crée des différences significatives dans le comportement des API SOAP et des API REST.

SOAP est l’acronyme de Simple Object Access Protocol, ou protocole simple d’accès aux objets, en français. Contrairement à REST, il est considéré comme un protocole, et non comme un style d’architecture.

Les API SOAP étaient les API les plus courantes avant l’arrivée de REST. REST utilise le protocole HTTP pour communiquer, SOAP d’un autre côté peut utiliser de multiples moyens de communication. Le souci, c’est la complexité qui en ressort, car les développeurs doivent se coordonner pour s’assurer qu’ils communiquent de la même manière afin d’éviter les problèmes. De plus, le SOAP peut demander plus de bande passante, ce qui entraîne des temps de chargement beaucoup plus longs. REST a été créé pour résoudre certains de ces problèmes grâce à sa nature plus légère et plus flexible.

De nos jours, le SOAP est plus fréquemment utilisé dans les applications de grandes entreprises, puisqu’on peut y ajouter des couches de sécurité, de confidentialité des données, et d’intégrité supplémentaires. REST peut être tout aussi sécurisé, mais a besoin d’être implémenté, c’est-à-dire d’être développé au lieu d’être juste intégré comme avec le SOAP.

Question 2

Quelles sont les similitudes entre SOAP et REST ?

Answer 2

Pour créer des applications, vous pouvez utiliser de nombreux langages de programmation, architectures et plateformes. Il est difficile de partager des données entre des technologies aussi variées, car elles utilisent des formats de données différents. SOAP et REST ont été créés pour tenter de résoudre ce problème.

Vous pouvez utiliser SOAP et REST pour créer des API ou des points de communication entre diverses applications. Les termes service Web et API sont utilisés de manière interchangeable. Toutefois, les API constituent la catégorie la plus large. Les services Web sont un type particulier d’API.

Voici d’autres similitudes entre SOAP et REST :

Ils décrivent tous deux les règles et les normes relatives à la manière dont les applications émettent les demandes de données provenant d’autres applications, les traitent et y répondent.
Ils utilisent tous deux HTTP, le protocole Internet standardisé, pour échanger des informations.
Ils prennent tous deux en charge le protocole SSL/TLS pour une communication sécurisée et cryptée.
Vous pouvez utiliser SOAP ou REST pour créer des systèmes distribués sécurisés, évolutifs et tolérants aux pannes.

Question 3

Api ?

Answer 3

API est une abbréviation et signifie Application Programming Interface (ou interface de programmation d’application, en français). Pour faire simple : c’est un moyen de communication entre deux logiciels, que ce soit entre différents composants d’une application ou entre deux applications différentes.

Une API, ou Interface de Programmation Applicative, est un ensemble de règles et de protocoles permettant à des logiciels différents de communiquer entre eux.
Elle définit les méthodes et les données qui peuvent être utilisées pour l’intégration de services ou de fonctionnalités spécifiques dans une application sans avoir à comprendre les détails internes de leur mise en œuvre.

Question 4

SOLID ?

Answer 4

L’approche SOLID est un ensemble de principes de conception orientée objet visant à créer des logiciels plus compréhensibles, flexibles et faciles à maintenir. Les cinq principes SOLID sont :

1. Single Responsibility Principle (SRP) : Une classe ne devrait avoir qu’une seule raison de changer, c’est-à-dire qu’elle ne devrait avoir qu’une seule responsabilité.
2. Open/Closed Principle (OCP) : Une classe doit être ouverte à l’extension, mais fermée à la modification. Cela signifie que le comportement d’une classe peut être étendu sans modifier son code source.
3. Liskov Substitution Principle (LSP) : Les objets d’une classe dérivée peuvent être utilisés à la place des objets de la classe de base sans affecter le bon fonctionnement du programme.
4. Interface Segregation Principle (ISP) : Il est préférable d’avoir plusieurs interfaces spécifiques plutôt qu’une interface générale. Cela évite aux classes d’implémenter des méthodes qu’elles n’utilisent pas.
5. Dependency Inversion Principle (DIP) : Les modules de haut niveau ne devraient pas dépendre des modules de bas niveau, mais plutôt des abstractions. Les abstractions ne devraient pas dépendre des détails, mais les détails devraient dépendre des abstractions.

En appliquant ces principes, on vise à créer un code plus modulaire, extensible et facilement adaptable aux changements.

Question 5

Singleton ?

Answer 5

En informatique, le terme “singleton” fait référence à un patron de conception (design pattern) qui garantit qu’une classe n’a qu’une seule instance et fournit un point d’accès global à cette instance. Cela signifie qu’une fois qu’une instance de la classe a été créée, toutes les futures demandes pour créer une nouvelle instance renverront la même instance existante.

Le but principal du modèle singleton est de contrôler l’accès à l’instance unique d’une classe afin de garantir qu’il n’y a qu’une seule instance de cette classe dans l’ensemble du système. Cela peut être utile dans des situations où une unique instance d’une classe doit coordonner des actions à travers le système, par exemple, un gestionnaire de configuration ou une connexion à une base de données.

Le singleton est mis en œuvre en restreignant la création d’instances de classe au sein de la classe elle-même, généralement en utilisant une méthode statique pour fournir l’instance unique et en garantissant que le constructeur de la classe est privé.

Question 6

Micro services ?

Answer 6

L’architecture microservices est un style d’architecture logicielle où une application est décomposée en un ensemble de services indépendants et autonomes, appelés microservices. Chaque microservice est conçu pour accomplir une tâche spécifique ou fournir une fonctionnalité distincte, et ces services interagissent entre eux à travers des API bien définies.

Les caractéristiques clés de l’architecture microservices comprennent :

1. Indépendance des Services : Chaque microservice est développé, déployé et évolue de manière indépendante. Cela permet aux équipes de travailler sur différents services sans affecter les autres parties de l’application.
2. APIs Définies : Les microservices communiquent entre eux via des interfaces API bien définies. Cela favorise la modularité et permet aux services de fonctionner de manière isolée tout en collaborant efficacement.
3. Évolutivité et Flexibilité : L’architecture microservices permet une évolutivité horizontale, ce qui signifie que chaque service peut être mis à l’échelle individuellement en fonction de la demande. Cela rend l’application plus flexible et capable de gérer des charges variables.
4. Resilience et Fiabilité : En cas de panne d’un microservice, le reste de l’application peut continuer à fonctionner normalement. Chaque microservice est conçu pour être résilient et capable de gérer ses erreurs.
5. Technologies Diverses : Chaque microservice peut être développé en utilisant la technologie la mieux adaptée à sa tâche. Cela permet l’utilisation de langages de programmation, de bases de données et de frameworks différents au sein de l’application.

L’architecture microservices est souvent choisie pour sa capacité à faciliter la gestion de grandes applications complexes, à permettre le déploiement continu, et à améliorer la flexibilité et l’agilité des équipes de développement. Cependant, elle nécessite une bonne gestion des communications entre les services et une infrastructure appropriée pour gérer le déploiement et la supervision des multiples services.

Question 7

Principaux design patterns ?

Answer 7

1. Singleton Pattern : Garantit qu’une classe a une seule instance et fournit un point d’accès global à cette instance.
2. Factory Method Pattern : Définit une interface pour la création d’un objet, mais laisse les sous-classes modifier le type d’objets qui seront créés.
3. Abstract Factory Pattern : Fournit une interface pour créer des familles d’objets liés ou dépendants sans spécifier leurs classes concrètes.
4. Builder Pattern : Permet la construction d’un objet complexe étape par étape. Utile lorsque la construction directe d’un objet est compliquée.
5. Prototype Pattern : Crée de nouveaux objets en copiant un objet existant, appelé le prototype, plutôt qu’en instanciant directement à partir d’une classe.
6. Adapter Pattern : Permet à l’interface d’une classe existante d’être utilisée comme une autre interface attendue.
7. Decorator Pattern : Attache de nouvelles responsabilités à un objet en le plaçant dans des objets décorateurs qui possèdent ces responsabilités.
8. Observer Pattern : Définit une dépendance un-à-plusieurs entre objets de manière à ce que lorsqu’un objet change d’état, tous ses dépendants soient notifiés et mis à jour automatiquement.
9. Strategy Pattern : Définit une famille d’algorithmes, encapsule chaque algorithme, et les rend interchangeables. Permet au client de choisir l’algorithme approprié à utiliser.
10. Command Pattern : Encapsule une requête comme un objet, permettant ainsi de paramétrer les clients avec des requêtes, d’encapsuler les requêtes, de les mettre dans une file d’attente, de les enregistrer, etc.
11. Chain of Responsibility Pattern : Passe la demande le long d’une chaîne de gestionnaires. Chaque gestionnaire décide s’il peut traiter la demande ou s’il doit la transmettre au gestionnaire suivant.
12. State Pattern : Permet à un objet de changer son comportement lorsqu’il change son état interne. L’objet apparaîtra comme ayant changé de classe.

Ces design patterns sont des solutions récurrentes à des problèmes courants de conception logicielle. La connaissance de ces patterns peut aider les développeurs à créer des solutions plus flexibles, modulaires et extensibles.

Question 8

Qu’est ce que ioc ?

Answer 8

IoC signifie “Inversion of Control” en anglais, ce qui se traduit en français par “Inversion de Contrôle”. Il s’agit d’un principe de conception utilisé en programmation informatique, particulièrement fréquent dans le développement d’applications basées sur des frameworks.

Dans le contexte de IoC, le contrôle de l’exécution d’un programme est inversé, signifiant que l’ordinateur ou le framework prend le contrôle du flux d’exécution au lieu que le programmeur le fasse directement. Cela se traduit souvent par le déplacement de la responsabilité de la gestion des dépendances et de la configuration du code de l’application vers un conteneur ou un framework.

Le conteneur IoC gère la création et la gestion des objets, permettant au développeur de se concentrer sur la logique métier de l’application plutôt que sur la gestion des dépendances. Les principaux mécanismes d’implémentation de l’IoC incluent l’injection de dépendances (Dependency Injection) et la configuration externe (généralement à travers des fichiers de configuration).

En résumé, IoC vise à rendre le code plus modulaire, souple et facilement testable en inversant le contrôle de certaines opérations du programmeur vers un framework ou un conteneur.

Question 9

Différence entre REST et RESTFUL

Answer 9

REST et RESTful sont deux termes couramment utilisés pour décrire les API Web. Cependant, il existe une différence importante entre les deux.
REST API (Representational State Transfer API):
REST est un style d’architecture pour les systèmes distribués.
Une API REST peut être simplement appelée une API REST, bien que ce terme soit parfois utilisé pour se référer à l’ensemble de l’architecture.
Les services REST sont basés sur des contraintes architecturales, telles que l’absence d’état, l’architecture orientée ressources, l’interface uniforme, etc.
RESTful API:
RESTful est un terme utilisé pour décrire les implémentations conformes aux principes REST.
Une API RESTful est une API qui suit les principes et les meilleures pratiques de REST de manière stricte.
Elle met en œuvre les contraintes REST, telles que l’utilisation appropriée des méthodes HTTP (GET, POST, PUT, DELETE), l’utilisation des URI (Uniform Resource Identifiers) pour identifier les ressources, et la représentation des ressources de manière étatique.
En résumé: la différence entre REST et RESTful est que REST est un ensemble de contraintes architecturales, tandis que RESTful est un terme utilisé pour décrire une API qui respecte ces contraintes.

Question 10

Qu’est-ce qu’une API RESTful ?

Answer 10

L’API RESTful est une interface que deux systèmes informatiques utilisent pour échanger des informations en toute sécurité sur Internet. La plupart des applications commerciales doivent communiquer avec d’autres applications internes et tierces pour accomplir différentes tâches. Par exemple, pour générer des fiches de paie mensuelles, votre système de comptabilité interne doit partager des données avec le système bancaire de votre client pour automatiser la facturation, et communiquer avec une application interne de feuille de temps. Les API RESTful prennent en charge ces échanges d’informations en suivant des standards de communication logiciels sûrs, fiables et efficaces.

Question 11

Qu’est-ce que REST ?

Answer 11

Representational State Transfer (REST) est une architecture logicielle qui impose des conditions sur la façon dont une API doit fonctionner. REST a été initialement créé comme une ligne directrice pour gérer la communication sur un réseau complexe comme l’Internet. Vous pouvez utiliser une architecture basée sur REST pour prendre en charge une communication performante et fiable à grande échelle. Vous pouvez facilement l’implémenter et le modifier, ce qui apporte visibilité et portabilité entre plateformes à tout système d’API.

Question 12

Quels sont les avantages de l’IoC ?

Answer 12

L’Inversion de Contrôle (IoC) est un concept de conception logicielle qui apporte plusieurs avantages, notamment :
1. Séparation des préoccupations (Separation of Concerns)
2. Réduction du couplage (Reduced Coupling)
3. Facilitation de la testabilité (Improved Testability)
4. Réutilisation des composants (Component Reusability)
5. Meilleure extensibilité (Improved Extensibility)
6. Facilitation de la configuration (Configuration Ease)
7. Meilleure compréhension du flux de contrôle (Improved Control Flow Understanding)

Question 13

Deux scalabilités ?

Answer 13

Scalabilité = Extensibilité (face à une montée en charge) //
Scaler vient de l’anglais to scale et signifie en quelques mots la capacité de votre application/logiciel/site internet à s’adapter et à fonctionner même en cas de forte augmentation soudaine du trafic, de demandes ou juste d’un grand nombre de fonctionnalités implémentées.

La scalabilité horizontale, ou évolutivité horizontale : elle consiste à ajouter des composants matériels pour satisfaire la demande. Il s’agit, par exemple, de s’équiper de plus de serveurs (même de manière temporaire) afin de faire face à une forte augmentation des flux et répartir les charges.

La scalabilité verticale, ou évolutivité verticale : elle se traduit par l’ajout de composants sur les machines déjà en place. Prenons l’exemple à nouveau des serveurs, qui peuvent bénéficier de ressources supplémentaires (processeur, mémoire, etc.) augmentant leurs performances.

Question 14

Api resource ?

Answer 14

Une ressource est un objet de type nominal utilisé pour sauvegarder des données dans une API.
Exemple un joueur est une resource d’une API NBA, un entraineur serait une autre resource.
Collections joueurs, entraineurs, ensemble d’une resource

Question 15

Comment faire de l’injection de dépendance ?

Answer 15

Il existe plusieurs moyens de faire de l’injection de dépendance, notamment :

1. Injection de dépendance par constructeur : Les dépendances sont passées au constructeur de la classe.
2. Injection de dépendance par propriété : Les dépendances sont injectées via des propriétés de la classe.
3. Injection de dépendance par méthode : Les dépendances sont passées à travers des méthodes dédiées.
4. Conteneurs d’injection de dépendance (IoC) : Utilisation de frameworks tels que Spring, Dagger, Guice, etc., qui gèrent l’injection de dépendance de manière automatique.
5. Service Locator : Utilisation d’un service locator pour obtenir des instances de dépendances.

Chaque approche a ses avantages et inconvénients, et le choix dépend souvent du contexte et des besoins spécifiques du projet.

Question 16

MVC

Answer 16

L’architecture MVC (Modèle-Vue-Contrôleur) est un paradigme de conception logicielle qui divise une application en trois composants interconnectés : le modèle (représentation des données et de la logique métier), la vue (interface utilisateur) et le contrôleur (gestion des entrées de l’utilisateur et mise à jour du modèle en conséquence). Cette séparation facilite la maintenance, l’extensibilité et la réutilisation du code.

Question 17

Architecture n tiers

Answer 17

L’architecture N-Tiers est un modèle de conception logicielle où une application est divisée en plusieurs couches distinctes, appelées “tiers”, chacune responsable de certaines fonctionnalités. Les trois principaux tiers sont généralement la présentation (interface utilisateur), la logique métier (traitement des données) et la persistance des données (stockage). Cette approche favorise la modularité, la scalabilité et la maintenance des systèmes informatiques.

Question 18

En quoi consistent les singletons ?

Answer 18

class SoundManager
{
// il faut garder en mémoire l’instance unique quelque part
// nous allons donc garder une variable statique

private static SoundManager _instance = null;

// comme n'importe quelle classe, il y a des attributs

private int currentSoundLevel;

// rendre le constructeur privé
// afin qu'il ne soit appelé par rien d'autre 
// que les méthodes de cette classe même

private SoundManager() {
    currentSoundLevel = 11;
}

// la méthode que les clients appellent pour accéder au singleton
public static SoundManager getInstance() {
    
    // si nous n'avons pas déjà d'instance, en créer une maintenant
    if (_instance == null)

        _instance = new SoundManager();

    // retourner celle que nous venons de faire
    // ou que nous avions déjà faite
    
    return _instance;
}

// rien de spécial à propos des autres méthodes

public void setVolume(int value) {
    currentSoundLevel = value;
}

}