Mise à jour de 'README.md'
continuous-integration/drone/push Build is passing Details

master
Théo DUPIN 2 years ago
parent 9ecb96e6c9
commit ff26c3f290

@ -167,4 +167,12 @@ StubData --> "*" RunePages
StubData --> "*" Skins
```
# API LOL
## Diagramme d'architecture
## Diagramme d'architecture
## Quelques explications
L'API que l'on devait mettre en place devait être conçue pour effectuer des opérations CRUD (Create, Read, Update, Delete) sur la base de données Entity Framework (EF). Pour ce faire, il a fallu commencer par mapper les classes métiers du modèle en entités pour la partie EF, afin de pouvoir interagir avec la base de données. Ensuite, il a fallu créer des classes de transfert de données (DTO) pour représenter les mêmes classes métiers du modèle, mais dans un format adapté à la communication avec l'API.
L'API a été conçue pour exposer les fonctionnalités CRUD de la base de données aux clients, tels que le client MAUI, qui aurait dû utilisé pour fournir une application mobile. La communication entre l'API et le client devait se faire via des requêtes HTTP, qui auraient été envoyées par le client à l'API pour effectuer des opérations sur la base de données.
Lorsqu'un utilisateur effectue une opération dans l'application mobile, telle que la création d'un nouvel objet, le client MAUI aurait dû une requête POST à l'API, contenant les informations sur l'objet à créer. L'API aurait donc dû recevoir cette requête, convertir les données du DTO en entités EF, puis les ajouter à la base de données. Puis, l'API aurait dû renvoyer une réponse HTTP au client, confirmant que l'opération a réussi.
De même, si l'utilisateur avait demandé de mettre à jour ou de supprimer un objet, le client MAUI aurait dû envoyer une requête PUT ou DELETE à l'API, qui aurait effectué les opérations correspondantes sur la base de données. L'API aurait ensuite envoyé une réponse HTTP au client pour indiquer si l'opération a réussi ou échoué.
Loading…
Cancel
Save