Apakah WSGI dan CGI dalam bahasa Inggris biasa?


126

Setiap kali saya membaca WSGI atau CGI saya merasa ngeri. Saya sudah mencoba membacanya sebelumnya tetapi tidak ada yang benar-benar macet.

Apa itu sebenarnya dalam bahasa Inggris?

Apakah itu hanya mengirimkan permintaan ke terminal dan mengarahkan output?


Jawaban:


60

WSGI menjalankan interpreter Python pada awal server web, baik sebagai bagian dari proses server web (mode tertanam) atau sebagai proses terpisah (mode daemon), dan memuat skrip ke dalamnya. Setiap permintaan menghasilkan fungsi khusus dalam skrip yang dipanggil, dengan lingkungan permintaan diteruskan sebagai argumen ke fungsi.

CGI menjalankan skrip sebagai proses terpisah setiap permintaan dan menggunakan variabel lingkungan, stdin, dan stdout untuk "berkomunikasi" dengannya.


15
WSGI! = Mod_wsgi. Bahasa Anda menyarankan Anda maksud mod_wsgi yang merupakan implementasi WSGI. WSGI sendiri hanyalah spesifikasi dan dapat diimplementasikan dengan berbagai cara, termasuk di atas CGI.
Graham Dumpleton

@Graham: Apakah Anda mengatakan bahwa tidak ada wadah WSGI lain yang mendukung menjalankan aplikasi WSGI dalam mode itu?
Ignacio Vazquez-Abrams

3
Secara teknis orang bisa mengatakan ada variasi yang lebih halus daripada hanya dua, paling tidak sebanyak bagaimana proses memulai atau bagaimana kode diaktifkan dalam sistem tertanam. Jadi seseorang harus berhati-hati dalam menggeneralisasi hal-hal menjadi dua kategori saja. Pada tingkat kotor Anda mungkin mengatakan apa yang Anda miliki, tetapi ada sedikit lebih dari itu jika Anda ingin menggali ke dalamnya.
Graham Dumpleton

1
@GrahamDumpleton, karena penasaran, maukah Anda menjelaskan bagaimana WSGI dapat diimplementasikan di atas CGI?
Yoland

2
Baca spesifikasi WSGI. Ini menunjukkan contoh jembatan CGI / WSGI. python.org/dev/peps/pep-3333/#the-server-gateway-side Untuk implementasi yang lebih kuat, lihat github.com/GrahamDumpleton/cgi2wsgi Namun, pada umumnya Anda ingin menghindari CGI.
Graham Dumpleton

255

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


21
Daripada membiarkan jawaban ini diakhiri dengan "tanya orang lain", saya berharap seseorang akan mengedit jawaban ini untuk memasukkan CGI dengan cara yang sama.
Bruno Bronosky

1
'server akan menjadi server dan perangkat lunak akan menjadi perangkat lunak' - 'server dari mars dan perangkat lunak dari venus' :)
Rahul

22

Jika Anda tidak jelas tentang semua istilah di ruang ini, dan mari kita hadapi itu, itu adalah akronim yang sarat membingungkan, ada juga pembaca latar belakang yang baik dalam bentuk python HOWTO resmi yang membahas CGI vs FastCGI vs WSGI dan sebagainya di. Saya berharap saya akan membacanya dulu.


21

Baik CGI dan WSGI mendefinisikan antarmuka standar yang dapat digunakan program untuk menangani permintaan web. Antarmuka CGI berada pada tingkat yang lebih rendah dari WSGI, dan melibatkan server menyiapkan variabel lingkungan yang berisi data dari permintaan HTTP, dengan program mengembalikan sesuatu yang diformat seperti respons server HTTP kosong.

WSGI, di sisi lain, adalah antarmuka tingkat-Python spesifik, sedikit lebih tinggi yang memungkinkan programmer untuk menulis aplikasi yang server-agnostik dan yang dapat dibungkus dengan aplikasi WSGI lainnya (middleware).

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.