Que sont WSGI et CGI en anglais simple?

126

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?

Blankman
la source

Réponses:

60

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.

Ignacio Vazquez-Abrams
la source
15
WSGI! = Mod_wsgi. Votre langage suggère que vous voulez dire mod_wsgi qui est une implémentation de WSGI. WSGI lui-même n'est qu'une spécification et peut être implémenté de nombreuses manières différentes, y compris au-dessus de CGI.
Graham Dumpleton
@Graham: Êtes-vous en train de dire qu'il n'y a pas d'autres conteneurs WSGI qui prennent en charge l'exécution d'applications WSGI dans ces modes?
Ignacio Vazquez-Abrams
3
Techniquement, on pourrait dire qu'il existe des variations plus subtiles que ces deux-là, du moins en ce qui concerne le démarrage des processus ou l'activation du code dans un système embarqué. Il faut donc être prudent en généralisant les choses dans ces deux catégories. À un niveau grossier, vous pourriez dire ce que vous avez, mais il y a un peu plus que cela si vous voulez approfondir.
Graham Dumpleton
1
@GrahamDumpleton, par curiosité, pourriez-vous expliquer comment WSGI peut être implémenté au-dessus de CGI?
Yoland
2
Lisez la spécification WSGI. Il montre un exemple de pont CGI / WSGI. python.org/dev/peps/pep-3333/#the-server-gateway-side Pour une implémentation plus robuste, voir github.com/GrahamDumpleton/cgi2wsgi Sérieusement, en général, vous voudriez éviter CGI.
Graham Dumpleton
255

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:

  • un processus client envoie une demande. Le processus client peut ê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
  • le serveur Web se repose à nouveau

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 :-)

Mark Henwood
la source
21
Plutôt que de laisser cette réponse se terminer par «demander à quelqu'un d'autre», j'aimerais que quelqu'un édite cette réponse pour inclure CGI de la même manière.
Bruno Bronosky
1
'les serveurs seront des serveurs et les logiciels seront des logiciels' - 'les serveurs sont de mars et le logiciel est de venus' :)
Rahul
22

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.

Richard Boardman
la source
21

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).

Wooble
la source