Que sont WSGI et CGI en anglais simple?
Chaque fois que je lis WSGI ou CGI, je grince des dents. J'ai déjà essayé de le lire, mais rien ne s'est vraiment coincé.
Qu'est-ce que c'est vraiment en anglais simple?
Transmet-il simplement des requêtes vers un terminal et redirige-t-il la sortie?
WSGI exécute l'interpréteur Python au démarrage du serveur Web, soit dans le cadre du processus du serveur Web (mode intégré), soit en tant que processus distinct (mode démon), et y charge le script. Chaque demande entraîne une fonction spécifique dans le script appelé, avec l'environnement de requête passé en arguments à la fonction.
CGI exécute le script comme un processus distinct à chaque demande et utilise des variables d'environnement, stdin et stdout pour "communiquer" avec lui.
D'un point de vue totalement en retrait, Blankman, voici ma "page d'introduction" pour l'interface de la passerelle des services Web:
PREMIÈRE PARTIE: SERVEURS WEB
Les serveurs Web fournissent des réponses. Ils s'assoient, attendant patiemment, puis sans aucun avertissement, soudain:
- un processus client envoie une demande. Le processus client pourrait être un serveur Web, un bot, une application mobile, peu importe. C'est simplement "le client"
- le serveur web reçoit cette demande
- marmonnement délibéré diverses choses se produisent (voir ci-dessous)
- Le serveur Web renvoie quelque chose au client
- serveur web se rassoit
Les serveurs Web (au moins, les meilleurs) sont très bons dans ce domaine. Ils augmentent et diminuent le traitement en fonction de la demande, ils ont des conversations fiables avec les clients les plus flaks sur des réseaux vraiment grossiers et nous n'avons jamais vraiment à nous en soucier. Ils continuent de servir.
C'est mon point: les serveurs Web ne sont que cela: des serveurs. Ils ne savent rien sur le contenu, rien sur les utilisateurs, rien d'autre que d'attendre beaucoup et répondre de manière fiable.
Votre choix de serveur Web doit refléter votre préférence de livraison, pas votre logiciel. Votre serveur Web doit être en charge du service et non du traitement ou des éléments logiques.
DEUXIÈME PARTIE: LOGICIEL (PYTHON)
Le logiciel ne fait pas défaut. Le logiciel n'existe qu'au moment de l'exécution. Le logiciel n'est pas très accommodant quand il s'agit de changements inattendus dans son environnement (les fichiers ne sont pas là où ils l'attendent, les paramètres sont renommés, etc.). Bien que l'optimisation doive être un principe central de votre conception (bien sûr), le logiciel lui-même ne s'optimise pas. Les développeurs optimisent. Le logiciel s'exécute. Le logiciel fait tout le travail dans la section "marmonnement délibéré" ci-dessus. Ça pourrait être n'importe quoi.
Votre choix ou conception de logiciel doit refléter votre application, votre choix de fonctionnalité et non votre choix de serveur Web.
C'est là que la méthode traditionnelle de "compilation en" langues vers des serveurs Web devient pénible. Vous finissez par mettre du code dans votre application pour faire face à l'environnement de serveur physique ou, au moins, être obligé de choisir une bibliothèque `` wrapper '' appropriée à inclure au moment de l'exécution, pour donner l'illusion d'uniformité entre les serveurs Web.
AINSI QUOI IS WSGI?
Alors, enfin, qu'est-ce que WSGI? WSGI est un ensemble de règles , écrit en deux moitiés. Ils sont rédigés de manière à pouvoir être intégrés dans n'importe quel environnement qui accueille l'intégration.
La première partie, écrite pour le côté serveur Web, dit "OK, si vous voulez gérer une application WSGI, voici comment le logiciel va penser quand il se charge. Voici les choses que vous devez mettre à la disposition de l'application, et ici est l'interface (mise en page) que vous pouvez attendre de chaque application. De plus, si quelque chose se passe mal, voici comment l'application va penser et comment vous pouvez vous attendre à ce qu'elle se comporte. "
La deuxième partie, écrite pour le logiciel d'application Python, dit "OK, si vous voulez traiter avec un serveur WSGI, voici comment le serveur pensera quand il vous contactera. Voici les choses vous devez mettre à la disposition du serveur, et voici l'interface (mise en page) que vous pouvez attendre de chaque serveur. De plus, si quelque chose se passe mal, voici comment vous devez vous comporter et voici ce que vous devez dire au serveur. "
Donc, vous l'avez - les serveurs seront des serveurs et les logiciels seront des logiciels, et voici un moyen pour qu'ils s'entendent parfaitement sans que l'un n'ait à tenir compte des spécificités de l'autre. C'est WSGI.
mod_wsgi, d'autre part, est un plugin pour Apache qui lui permet de parler à un logiciel compatible WSGI, en d'autres termes, mod_wsgi est une implémentation - dans Apache - des règles de la première partie du livre de règles ci-dessus.
Quant à CGI .... demandez à quelqu'un d'autre :-)
Si vous n'êtes pas clair sur tous les termes de cet espace, et avouons-le, c'est un acronyme déroutant, il y a aussi un bon lecteur de fond sous la forme d'un officiel python = HOWTO qui traite de CGI vs FastCGI vs WSGI et ainsi de suite. J'aimerais bien le lire en premier.
CGI et WSGI définissent des interfaces standard que les programmes peuvent utiliser pour gérer les requêtes Web. L'interface CGI est à un niveau inférieur à WSGI et implique que le serveur configure des variables d'environnement contenant les données de la requête HTTP, le programme retournant quelque chose formaté à peu près comme une réponse de serveur HTTP nue.
WSGI, d'autre part, est une interface spécifique à Python, légèrement supérieure qui permet aux programmeurs d'écrire des applications indépendantes du serveur et qui peuvent être encapsulées dans d'autres applications WSGI (middleware).