Distinction entre API et frontend-backend
J'essaie d'écrire un site Web d'entreprise "standard". Par "standard", je veux dire que ce site exécute le HTML5, CSS et Javascript habituel pour le front-end, un back-end (pour traiter les trucs) et exécute MySQL pour la base de données. C'est un site CRUD de base: le front-end fait juste ce que la base de données a en magasin; le backend écrit dans la base de données tout ce que l'utilisateur entre et effectue un traitement. Tout comme la plupart des sites.
En créant mes référentiels Github pour commencer à coder, j'ai réalisé que je ne comprenais pas la distinction entre le front-end back-end, et le [~ # ~] api [~ # ~]. Une autre façon de formuler ma question est: où l'API entre-t-elle dans cette image?
Je vais énumérer quelques détails supplémentaires, puis les questions que j'ai - j'espère que cela vous donnera une meilleure idée de ma véritable question, car je suis tellement confus que je ne connais pas la question précise à poser.
Quelques détails supplémentaires:
- Je voudrais essayer le modèle Model-View-Controller. Je ne sais pas si cela change la question/réponse.
- L'API sera RESTful
- J'aimerais que mon back-end utilise ma propre API au lieu de permettre au back-end de tricher et d'appeler des requêtes spéciales. Je pense que ce style est plus cohérent.
Mes questions:
- Le front-end appelle-t-il le back-end qui appelle l'API? Ou le front-end appelle-t-il simplement l'API au lieu d'appeler le back-end?
- Le back-end exécute-t-il simplement une API et l'API renvoie le contrôle au back-end (où le back-end agit comme le contrôleur ultime, déléguant des tâches)?
Des réponses longues et détaillées expliquant le rôle de l'API aux côtés du back-end front-end sont encouragées. Si la réponse dépend du modèle de programmation (modèles autres que le modèle Model-View-Controller), veuillez décrire ces autres façons de penser l'API. Merci. Je suis très confus.
Je pense que vous êtes confus par la façon dont le terme API est utilisé à mauvais escient et abusé par de nombreux développeurs Web.
- API signifie Application Programming Interface, c'est-à-dire toute interface officiellement spécifiée entre différents systèmes (ou parties du même système).
- Il y a quelque temps, il était devenu important pour le démarrage Web d'offrir un accès public à certaines de leurs données internes via une API de service Web, en utilisant généralement REST et JSON, permettant ainsi aux développeurs tiers de Les développeurs Web ont commencé à utiliser le terme "API" pour signifier spécifiquement (et uniquement) "service Web accessible au public", et à en abuser pour inclure sa mise en œuvre.
- En termes de frontend et de backend, cette API de service web (et son implémentation) est le backend. Certaines parties peuvent être accessibles au public et d'autres uniquement à votre frontend.
- Un nom différent pour cela est "couche de service", c'est-à-dire un code qui
- représente les services que le frontend appelle
- ne contient aucune logique d'affichage (c'est le travail du frontend, après tout)
- est plus abstrait et plus grossier que les actions CRUD simples (un appel de service impliquera souvent plusieurs actions CRUD et devrait être exécuté dans une transaction de base de données).
- contient la logique métier de l'application
Esquissons l'architecture d'un site web "typique", avec à la fois un "front-end" et un "back-end". Et comme c'est un site internet, nous aurons aussi explicitement un "client". (Puisqu'il n'y a aucun moyen pour JavaScript dans un navigateur d'appeler directement MySQL sur un serveur.)
Pour plus de clarté, les termes que nous utilisons sont:
- Client : Le navigateur compatible HTML5, esp. le DOM et le JavaScript sont chargés pour le manipuler.
- Front-End : Le serveur PHP vers lequel le DOM est pointé, contenant à la fois la page individuelle demandée et certains = AJAX style points d'accès XML ou JSON.
- Back-end : Un serveur de base de données, où MySQL s'exécute.
Pour un programme correctement conçu, chacun de ces composants possède une API privée pour communiquer avec les autres. Le "front-end" PHP n'émet pas directement des instructions SQL SELECT arbitraires, mais appelle plutôt des procédures stockées, du SQL pré-autorisé ou même des PHP appelle une instance entièrement différente de PHP qui exécute sur le serveur principal. Ces procédures stockées ou appels HTTP distincts sont eux-mêmes un API.
La définition ne change pas même si nous autorisons une certaine impureté de notre conception. Si votre fichier PHP écrit et envoie une chaîne SQL directement à MySQL, IT IS STILL AN API , quoique très inhabituel que vous ne répéterez probablement pas.
Notez qu'il est tout à fait possible que votre PHP frontal soit strictement synchrone, sans aucun AJAX vaudou que ce soit. Si vous appelez les mêmes fonctions externes PHP dans ledit fichier synchrone, vous pouvez les considérer comme utilisant la même API que la version côté client, bien que l'utilisation du terme "API" ici ne donne pas vraiment de clarté.
Une API en tant que Application Programming Interface , après tout, et fait vraiment référence à chaque fois qu'un programme appelle en dehors de son propre processus. Si vous écrivez un projet qui a à la fois un front-end et un back-end, que ce soit AJAX/PHP/MySQL comme ci-dessus ou MS Access/SQL Server, il vaut la peine de spécifier explicitement comment vous vous appellerez, si ce n'est pour aucune autre raison que de faire il est facile de savoir où chercher en cas de rupture.
(Et le sujet de API publique est tout autre chose. Dans notre exemple ci-dessus, seule l'URL affichée dans le client est une "API publique". le reste est, par essence, "privé". Comme dans le cas, vous ne vous attendez pas à ce qu'un code indépendant de votre volonté appelle votre API interne, et vous refusez carrément de tels résultats ou vous vous réservez le droit de le faire à l'avenir.