Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Candidat au Club
    Créer un serveur asp.net en back et de l'attaquer en utilisant les api uniquement
    Bonjour,

    J'ai pu lire beaucoup de choses sur les API.
    J'ai pu comprendre que les api sont utilisées pour QUELQUES fonctionnalités d'une application.
    Et que bien souvent, les API sont disponibles a partir du serveur WEB.

    Cela m'a donné une petite idée sur laquelle je n'ai pas trouvé beaucoup de réponse sur sa faisabilité.
    J'aimerai pousser le truc un peu plus loin.

    La voici:
    Est-il possible de créer un serveur asp.net en back qui communiquerait UNIQUEMENT via ses API en REST.
    Et ce serveur pourrait être consommé DIRECTEMENT par un site WEB (qui n'est pas hébergé sur le même serveur) ou une application mobile android ou IOS ou même une application locale (sans intermédiaire directement via cette API REST).

    Je demande cela car j'aimerai faire un projet sur ce principe.
    J'aimerai faire cela car ce serait un gain de temps énorme.

    Le serveur contiendrait uniquement les données et la logique métier.
    Et les différentes applications web/local/mobile auraient uniquement la logique d'affichage.
    L'application permettrai de consulter, ajouter modifier du contenu, peut importe la plateforme d'affichage.

    J'espère que mes explications sont compréhensibles.

    Si oui, de votre point de vu, quels sont les inconvénients et les avantages, avez vous des retours d’expériences à faire partager?

    Merci d'avance pour l'aide.


  2. #2
    Expert éminent sénior
    oui je pense que c'est possible.

    Citation Envoyé par la-gachette Voir le message
    Et ce serveur pourrait être consommé DIRECTEMENT par un site WEB (qui n'est pas hébergé sur le même serveur)
    cela veut dire que le client web envoie une requête HTTP à l'application web qui elle même envoie une requête HTTP au serveur de l'API.

    j'ai plutôt l'habitude de travailler avec une application web qui contient directement l'API donc je n'ai pas d'expérience sur les 2 serveurs séparés.
    après une 1re lecture de votre message je pense que la seule raison de séparer les 2 serait que chacun ait besoin de toute la puissance de la machine sur laquelle le serveur est. avec un inconvénient qui serait une perte de temps à cause de la double communication.

  3. #3
    Candidat au Club
    Je vous remercie pour ce retour.
    Je suis d'accord avec vous sur le fait que séparer le site web et le serveur applicatif en back n'est pas super en terme de performance.
    D'après vous la meilleure idée serait de mettre le serveur web sur la même machine que le serveur applicatif et qu'ils communiquent via l'api?

    Je ne veux surtout pas avoir un code redondant dans le serveur en back et le serveur Web.
    Le serveur web ne contiendrait que la partie affichage.

    Est-ce que je me trompe dans mon raisonnement au niveau de l'utilisation des api et de l'architecture de l'installation?

    Merci d'avance.

  4. #4
    Candidat au Club
    Personne d'autre n'a de retour à partager sur ce genre d'architecture d'application?