Langkah pertama dalam bekerja dengan web adalah mengirim data ke aplikasi server Anda. Dan jika parsing selusin garis kecil dapat dipercayakan ke kerangka kerja, lalu bagaimana dengan mengunduh file?
Mari kita ambil PHP sebagai contoh, meskipun yang dijelaskan adalah benar untuk 99% dari bahasa dan teknologi lainnya. Misalkan kita ingin mengizinkan pengguna untuk mengunggah gambar ke situs, untuk ini kita membuat formulir dengan bidang jenis file dan ... Secara lahiriah, semuanya sangat sederhana, hanya beberapa byte dalam formulir dan dalam kode telah berubah, tetapi sekarang Anda dapat bekerja dengan file alih-alih teks dari formulir! Tapi tidak semuanya begitu sederhana, file Anda harus diselesaikan di suatu tempat di / tmp / sampai permintaan diterima sepenuhnya, skrip Anda sama sekali tidak mendapatkan kontrol dan Anda tidak dapat melakukan apa-apa. Misalnya, alih-alih gambar, pengguna mengunggah file exe, tetapi Anda hanya akan mengetahuinya setelah unduhan akhirnya selesai. Dengan demikian, penyerang dapat untuk beberapa waktu memalu saluran dan waktu subsistem disk Anda, pura-pura memuat file yang berguna, dan Anda bahkan tidak akan mengetahuinya. Jika server caching ada di depan server aplikasi, situasinya bahkan lebih buruk: misalnya, nginx membuat file sementara, mis. pertama, permintaan dari pengguna akan diselesaikan pada disk, segera setelah selesai, file tersebut dibaca kembali dan dengan cepat diberikan ke server aplikasi (dalam kasus kami, php), di mana ia disimpan ke disk SEKALI LAGI. Penggunaan triple total disk, bahkan jika pengguna hanya perlu menampilkan pesan "Anda lupa memasukkan captcha."
Saya tidak berbicara tentang fakta bahwa lebih banyak hal menyenangkan dengan pendekatan ini tidak dapat dilakukan. Fitur sederhana seperti "bilah kemajuan pengunggahan file" menjadi tidak tersedia. Untuk contoh yang lebih kompleks: Youtube menunjukkan bingkai dari film yang masih dimuat tetapi tidak dimuat sepenuhnya. Anda tidak akan mendapatkan kendali apa pun (dan bahkan notifikasi!) Sebelum seluruh film (2 gigabytes, misalnya) diunduh. Anda bahkan tidak tahu bahwa seseorang telah memakan 1,5 gigabyte disk Anda, tetapi kemudian tutup browser atau mengklik tombol refresh di browser tanpa menunggu apa pun.
Tentu saja, ada berbagai kruk dengan berbagai tingkat kelengkungan yang memungkinkan Anda untuk menyelesaikan tugas-tugas khas, seperti "menerima statistik permintaan melalui json", diimplementasikan sebagai modul server web, tetapi Anda harus melakukan hal-hal seperti itu sendiri dan / atau dengan demikian menjadi melekat pada lingkungan, aplikasi berhenti menjadi independen dan menjadi tergantung pada aplikasi spesifik dan pustaka mereka.
Cache
Cache sangat penting. Teknik caching memungkinkan Anda untuk mempercepat daya tanggap situs Anda dan mengurangi beban di atasnya, menghilangkan keharusan untuk melakukan operasi yang sama untuk banyak permintaan. Misalnya, berapa banyak yang tidak melakukan 2 + 2, akan selalu ada 4, tetapi komputasi 2 + 2 memakan sumber daya server, jauh lebih menguntungkan untuk menghitung nilai ini 1 kali, ketika pengunjung pertama tiba, dan kemudian menulis di suatu tempat, untuk memberikan pengguna lain ini keluar hasil.
Jangan bingung caching ini dengan header http, mereka hanya berpengaruh pada klien tertentu (dalam aslinya juga pada proksi perantara), sementara caching di server dirancang untuk memberikan konten yang sama kepada banyak pengguna.
Sayangnya, tidak menguntungkan untuk memberikan caching ke server perantara, jika ada pembaruan sekecil apa pun pada suatu halaman, Anda harus membuat halaman dari awal, dan diberikan realitas modern, ketika ada banyak elemen dinamis pada sebuah halaman, maka pada kenyataannya setiap halaman akan unik, dan di sisi lain, setiap permintaan berupa GET / somepage.html? someshit = 12345 akan menerobos cache dan halaman baru akan terbentuk yang bahkan tidak akan mempertimbangkan parameter ini, tetapi bagaimanapun akan ada biaya untuk pembuatannya, yang lagi-lagi dapat digunakan oleh penyerang. Oleh karena itu, beberapa orang menggunakan server cache perantara dan sudah sangat sulit untuk mengandalkannya.
Masih menyimpan semua yang ada di dalam aplikasi, hampir setiap kerangka kerja menyediakan kruk sendiri, serta kruk siap pakai seperti semua jenis memo dan sejenisnya. Biasanya, pengembang pemula hanya menulis dalam air mendidih ketika mereka mengetahui bahwa saat membuat halaman, Anda dapat membuat 500 permintaan ke memcached dan tidak akan ada apa-apa untuk itu (tidak seperti mysql favorit semua orang). Akibatnya, semua kode ditutupi dengan pembungkus, yang pertama memeriksa hasil permintaan di memcache, dan kemudian mereka naik setelah hasilnya di mysql. Saya tidak berpendapat, kontrol manual dari cache diperlukan, tetapi kontrol manual sepenuhnya mengarah ke kemungkinan kesalahan, di mana Anda bisa lupa untuk mengaktifkan caching, yang, menurut hukum kekejaman, akan menjadi tempat yang kritis.
Antarmuka
Antarmuka apa yang harus dimiliki situs? Hanya saja, jangan katakan itu hijau.
Sebelumnya, biasanya, penyajian situs bersifat tunggal dan tidak terpisahkan. Namun, pada portal besar terdapat tombol "versi cetak", atau bahkan "versi wap", yang kemudian digantikan oleh "versi PDA" - sudah HTML biasa, hanya lebih sederhana. Meskipun tergantung di mana, jika Anda menggunakan Twitter, maka ini adalah satu-satunya versi yang dapat dibaca. Waktu berlalu dan ada kebutuhan untuk mengedit situs tidak hanya untuk printer dan telepon, tetapi juga untuk semua jenis iPad dan lemari es dengan dukungan HTML5. Secara alami, ini semua jatuh cinta kepada pengembang, karena mereka sebenarnya harus melakukan 10 versi dari masing-masing situs, dan mereka memutuskan untuk melakukan sesuatu yang universal. Semacam API untuk situs tersebut.
Apa itu API - saya tidak tahu. Jujur saja, saya tidak tahu. Biasanya ini semacam omong kosong ketika Anda meludahi server dengan seutas string urlencode, dan sebagai imbalannya Anda mendapatkan sepotong json / xml / teks biasa, betapa beruntungnya itu. Tentu saja, tidak ada standar, bahkan tipe data primitif, bisa apa saja, hasil kosong juga bisa apa saja, dari nol hingga "" (tanda kutip kosong), atau bahkan tidak ada sebagai hasilnya. Adalah baik jika penulis membaca tentang kata seperti REST dan bergegas untuk mengimplementasikannya, tetapi dengan latar belakang yang lain, itu tidak masuk akal. Fungsionalitasnya juga tidak jelas, jika dengan meminta halaman HTML kita bisa mendapatkan semuanya sekaligus (berita terbaru, komentar, suka, dll.), Lalu berapa banyak permintaan yang perlu kita buat jika terjadi API - hanya pembuat API ini yang tahu, itu sangat mungkin bahwa komentar dapat diterima, tetapi suka - tidak. Faktanya, API adalah cara untuk membagi pengembangan klien dan server menjadi tim pengembangan yang sangat berbeda yang berinteraksi buruk satu sama lain. Dan tidak ada pembicaraan tentang kegunaan API ini.
Dan sering terjadi bahwa mengakses API memerlukan kunci tertentu. Kunci sering dapat diperoleh secara gratis. Mengapa tidak mendapatkan kunci seperti itu? Masalahnya adalah ini menuntun kita ke akuntansi permintaan eksplisit, ke beberapa akuntansi internal. Dan siapa yang tahu kapan penulis ingin memonetisasi semua ini? Ada kemungkinan bahwa setelah beberapa waktu kunci gratis akan dinonaktifkan atau sangat terbatas, menawarkan untuk menggunakan tarif berbayar. Dan kadang-kadang secara umum, penerbitan semua kunci ditunda, dan layanan dihentikan, bahkan secara komersial, ini juga terjadi. Nah, mengapa API? Lebih mudah bagi saya untuk merentangkan halaman dan menguraikannya dengan pelanggan tetap daripada menanggung aib seperti itu. Karena itu, saya hampir tidak pernah menggunakan API ini, terutama karena saya tidak akan berurusan dengan fitur-fiturnya.