Dari sudut pandang yang sepenuhnya mundur, Blankman, inilah "Halaman Intro" saya untuk Antarmuka Gateway Layanan Web:
BAGIAN SATU: SERVER WEB
Server web menyajikan respons. Mereka duduk-duduk, menunggu dengan sabar, dan kemudian tanpa peringatan sama sekali, tiba-tiba:
- proses klien mengirim permintaan. Proses klien dapat berupa server web, bot, aplikasi seluler, apa pun. Ini hanyalah "klien"
- server web menerima permintaan ini
- sengaja menggumamkan berbagai hal terjadi (lihat di bawah)
- Server web mengirim kembali sesuatu ke klien
- server web duduk kembali
Server web (setidaknya, yang lebih baik) sangat SANGAT bagus dalam hal ini. Mereka meningkatkan dan menurunkan proses tergantung pada permintaan, mereka andal mengadakan percakapan dengan klien paling tipis di jaringan yang benar-benar kasar dan kami tidak pernah benar-benar perlu khawatir tentang hal itu. Mereka terus melayani.
Ini poin saya: server web hanya itu: server. Mereka tidak tahu apa-apa tentang konten, tidak ada tentang pengguna, tidak ada yang sebenarnya selain bagaimana menunggu banyak dan menjawab dengan andal.
Server web pilihan Anda harus mencerminkan preferensi pengiriman Anda, bukan perangkat lunak Anda. Server web Anda harus bertugas melayani, bukan memproses atau hal-hal yang logis.
BAGIAN DUA: PERANGKAT LUNAK (PYTHON)
Perangkat lunak tidak tinggal diam. Perangkat lunak hanya ada pada waktu pelaksanaan. Perangkat lunak tidak terlalu akomodatif ketika datang ke perubahan yang tidak terduga di lingkungannya (file tidak sesuai dengan yang diharapkan, parameter diubah namanya dll). Meskipun optimisasi harus menjadi prinsip utama dari desain Anda (tentu saja), perangkat lunak itu sendiri tidak mengoptimalkan. Pengembang mengoptimalkan. Perangkat lunak dieksekusi. Perangkat lunak melakukan semua hal di bagian 'mum sengaja' di atas. Bisa apa saja.
Pilihan atau desain perangkat lunak Anda harus mencerminkan aplikasi Anda, fungsionalitas pilihan Anda, dan bukan server web pilihan Anda.
Di sinilah metode tradisional "kompilasi dalam" bahasa ke server web menjadi menyakitkan. Anda akhirnya menempatkan kode dalam aplikasi Anda untuk mengatasi lingkungan server fisik atau, setidaknya, dipaksa untuk memilih perpustakaan 'pembungkus' yang sesuai untuk disertakan saat runtime, untuk memberikan ilusi keseragaman di seluruh server web.
JADI APA WSGI?
Jadi, akhirnya, apa itu WSGI? WSGI adalah seperangkat aturan , ditulis dalam dua bagian. Mereka ditulis sedemikian rupa sehingga mereka dapat diintegrasikan ke dalam lingkungan apa pun yang menyambut integrasi.
Bagian pertama, ditulis untuk sisi server web, mengatakan "OK, jika Anda ingin berurusan dengan aplikasi WSGI, inilah cara perangkat lunak akan berpikir ketika memuat. Berikut adalah hal-hal yang harus Anda sediakan untuk aplikasi tersebut, dan di sini adalah antarmuka (tata letak) yang dapat Anda harapkan dari setiap aplikasi. Selain itu, jika ada yang salah, berikut adalah bagaimana aplikasi akan berpikir dan bagaimana Anda dapat mengharapkannya berperilaku. "
Bagian kedua, ditulis untuk perangkat lunak aplikasi Python, mengatakan "OK, jika Anda ingin berurusan dengan server WSGI, berikut adalah cara server akan berpikir ketika menghubungi Anda. Berikut adalah hal-hal yang harus Anda sediakan untuk server, dan ini adalah antarmuka (tata letak) yang dapat Anda harapkan dari setiap server. Selain itu, jika ada yang salah, inilah yang harus Anda lakukan dan inilah yang harus Anda beri tahu server. "
Jadi begitulah - server akan menjadi server dan perangkat lunak akan menjadi perangkat lunak, dan inilah cara mereka bisa rukun tanpa harus membuat kelonggaran untuk spesifik yang lain. Ini WSGI.
mod_wsgi, di sisi lain, adalah plugin untuk Apache yang memungkinkannya berbicara dengan perangkat lunak yang sesuai dengan WSGI, dengan kata lain, mod_wsgi adalah implementasi - di Apache - aturan bagian satu dari buku aturan di atas.
Sedangkan untuk CGI .... tanya orang lain :-)