Chaque fois que je lis WSGI ou CGI, je grince des dents. J'ai déjà essayé de le lire mais rien n'est vraiment resté.
Qu'est-ce que c'est vraiment en anglais simple?
Dirige-t-il simplement les demandes vers un terminal et redirige-t-il la sortie?
Réponses:
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 séparé (mode démon), et y charge le script. Chaque requête entraîne l'appel d'une fonction spécifique dans le script, l'environnement de requête étant transmis en tant qu'arguments à la fonction.
CGI exécute le script comme un processus distinct à chaque demande et utilise les variables d'environnement, stdin et stdout pour «communiquer» avec lui.
D'un point de vue totalement rétrospectif, Blankman, voici ma "page d'introduction" pour l'interface de passerelle des services Web:
PREMIÈRE PARTIE: SERVEURS WEB
Les serveurs Web servent des réponses. Ils s'assoient, attendant patiemment, puis sans avertissement du tout, soudain:
Les serveurs Web (du moins, les meilleurs) sont très TRÈS bons dans ce domaine. Ils augmentent et réduisent le traitement en fonction de la demande, ils entretiennent de manière fiable des conversations avec les clients les plus délicats sur des réseaux vraiment grossiers et nous n'avons jamais vraiment à nous en soucier. Ils continuent juste à servir.
C'est mon point: les serveurs Web ne sont que cela: des serveurs. Ils ne savent rien du contenu, rien des utilisateurs, rien d'autre que de savoir comment attendre beaucoup et répondre de manière fiable.
Votre choix de serveur Web doit refléter vos préférences de livraison, pas votre logiciel. Votre serveur Web doit être en charge de la diffusion et non du traitement ou de la logique.
DEUXIÈME PARTIE: LOGICIEL (PYTHON)
Le logiciel ne reste pas là. 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ù il l'attend, les paramètres étant 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 toutes les choses dans la section «marmonnement délibéré» ci-dessus. Ça pourrait être n'importe quoi.
Votre choix ou la conception de votre logiciel doit refléter votre application, votre choix de fonctionnalités et non votre choix de serveur Web.
C'est là que la méthode traditionnelle de "compilation en" des langages vers des serveurs Web devient pénible. Vous finissez par mettre du code dans votre application pour faire face à l'environnement du 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.
QU'EST-CE QUE WSGI?
Alors, enfin, qu'est-ce que WSGI? WSGI est un ensemble de règles , écrites en deux moitiés. Ils sont rédigés de telle manière qu'ils peuvent ê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 ce que vous devez mettre à disposition de l'application, et ici est l'interface (mise en page) que vous pouvez attendre de chaque application. De plus, si quelque chose ne va pas, 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 va penser quand il vous contacte. Voici ce que vous devez mettre à la disposition du serveur, et voici l'interface (mise en page) que vous pouvez vous attendre à ce que chaque serveur ait. De plus, si quelque chose ne va pas, voici comment vous devez vous comporter et voici ce que vous devez dire au serveur. "
Donc là vous l'avez - les serveurs seront des serveurs et les logiciels seront des logiciels, et voici une façon dont ils peuvent tout simplement bien s'entendre sans que l'un 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 HOWTO python officiel qui discute CGI vs FastCGI vs WSGI et ainsi sur. J'aurais aimé 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 renvoyant quelque chose de formaté à peu près comme une réponse de serveur HTTP nue.
WSGI, d'autre part, est une interface de niveau légèrement plus élevé spécifique à Python qui permet aux programmeurs d'écrire des applications qui sont indépendantes du serveur et qui peuvent être encapsulées dans d'autres applications WSGI (middleware).