Halo, Penduduk! Jika pemrograman itu seperti sihir, maka web scraping adalah sihir yang sangat kuat. Dengan menulis program otomatis sederhana, Anda dapat mengirim permintaan ke server web, meminta data dari mereka, lalu menganalisisnya dan mengekstrak informasi yang Anda butuhkan. Edisi baru yang diperpanjang dari buku ini tidak hanya memperkenalkan web scraping, tetapi juga membantu mengumpulkan segala jenis data di Internet modern. Bagian I berfokus pada mekanisme pengikisan web: cara menggunakan Python untuk meminta informasi dari server web, melakukan pemrosesan respons server dasar, dan mengatur interaksi otomatis dengan situs. Bagian II membahas alat dan aplikasi yang lebih spesifik yang berguna dalam skenario scraping web apa pun. - Parse halaman HTML yang kompleks.- Kembangkan robot pencarian menggunakan kerangka Scrapy. - Pelajari cara menyimpan data bekas. - Membaca dan mengekstrak data dari dokumen. - Membersihkan dan menormalkan data yang diformat dengan buruk. - Membaca dan menulis informasi dalam bahasa alami. - Kuasai pencarian formulir dan login. - Pelajari pengikisan JavaScript dan pekerjaan API. - Gunakan dan tulis program untuk mengubah gambar menjadi teks. - Belajar untuk melewati perangkap gesekan dan pemblokir bot. - Uji situs web Anda sendiri dengan scraping.- Pelajari pengikisan JavaScript dan pekerjaan API. - Gunakan dan tulis program untuk mengubah gambar menjadi teks. - Belajar untuk melewati perangkap gesekan dan pemblokir bot. - Uji situs web Anda sendiri dengan scraping.- Pelajari pengikisan JavaScript dan pekerjaan API. - Gunakan dan tulis program untuk mengubah gambar menjadi teks. - Belajar untuk melewati perangkap gesekan dan pemblokir bot. - Uji situs web Anda sendiri dengan scraping.
Merayapi web dengan API
JavaScript secara tradisional dianggap sebagai kutukan universal perayap web. Dahulu kala, Anda dapat yakin bahwa permintaan yang Anda kirim ke server web akan menerima data yang sama dengan yang akan dilihat pengguna di browser mereka dengan membuat permintaan yang sama.
Karena metode JavaScript dan Ajax untuk menghasilkan dan memuat konten berkembang biak, situasi yang dijelaskan di atas menjadi kurang umum. Di Bab 11, kami melihat satu cara untuk memecahkan masalah ini: menggunakan Selenium untuk mengotomatiskan browser dan mengambil data. Ini mudah untuk dilakukan. Ini hampir selalu berhasil.
Masalahnya adalah ketika Anda memiliki palu sekuat dan seefektif Selenium di tangan Anda, setiap tugas mengikis jaring mulai terasa seperti paku.
Dalam bab ini, Anda akan mempelajari bagaimana, dengan melewati semua JavaScript ini (tanpa menjalankan atau bahkan memuatnya!), Anda dapat langsung mengakses sumber data - API yang menghasilkan data tersebut.
Pengantar Singkat tentang API
Ada banyak sekali buku, pembicaraan, dan tutorial tentang nuansa REST API, GraphQL21, JSON, dan XML, tetapi semuanya didasarkan pada satu konsep sederhana. API mendefinisikan sintaks standar yang memungkinkan satu program untuk berinteraksi dengan yang lain, meskipun mereka ditulis dalam bahasa yang berbeda atau memiliki struktur yang berbeda.
Bagian ini berfokus pada API web (khususnya yang memungkinkan server web berinteraksi dengan browser), dan di sini yang kami maksud dengan API jenis antarmuka ini. Namun perlu diingat bahwa dalam konteks lain, API juga merupakan istilah umum yang dapat berarti, misalnya, antarmuka yang memungkinkan program Java berinteraksi dengan program Python yang berjalan di komputer yang sama. API tidak selalu berarti "antarmuka melalui Internet" dan tidak perlu menyertakan teknologi web apa pun.
API Web paling sering digunakan oleh pengembang untuk berinteraksi dengan layanan sumber terbuka yang diiklankan secara luas dan terdokumentasi dengan baik. Misalnya, saluran TV olahraga kabel Amerika ESPN menyediakan API (http://www.espn.com/apis/devcenter/docs/) untuk informasi tentang atlet, skor pertandingan, dll. Google memiliki bagian pengembang (https: / /console.developers.google.com) ada lusinan API untuk terjemahan bahasa, analitik, dan geolokasi.
Dokumentasi untuk semua API ini biasanya menjelaskan rute atau titik akhir dalam bentuk URL yang dapat diminta, dengan parameter yang dapat berubah, baik sebagai bagian dari URL ini, atau bertindak sebagai parameter GET.
Misalnya, di URL berikut, pathparam adalah parameter jalur:
example.com/the-api-route/pathparam
Dan di sini pathparam adalah nilai parameter param1:
example.com/the-api-route?param1=pathparam
Kedua metode mentransfer data ke API digunakan cukup luas, meskipun, seperti banyak aspek lain dari ilmu komputer, menjadi subjek diskusi filosofis yang hangat tentang kapan dan di mana variabel harus dilewatkan melalui jalur, dan kapan - melalui parameter.
Respons terhadap permintaan API biasanya dikembalikan dalam format JSON atau XML. Saat ini JSON jauh lebih populer daripada XML, tetapi XML terkadang juga dijumpai. Banyak API memungkinkan Anda memilih jenis respons, biasanya dengan parameter lain yang menentukan jenis respons yang ingin Anda terima.
Berikut adalah contoh respons JSON untuk permintaan API:
{"user":{"id": 123, "name": "Ryan Mitchell", "city": "Boston"}}
Dan berikut adalah respon permintaan API dalam format XML:
<user><id>123</id><name>Ryan Mitchell</name><city>Boston</city></user>
Situs ip-api.com (http://ip-api.com/) memiliki API yang jelas dan nyaman yang mengubah alamat IP menjadi alamat fisik yang sebenarnya. Anda dapat mencoba
membuat permintaan API sederhana dengan mengetikkan ip-api.com/json/50.78.253.58 berikut ke dalam browser Anda,
dan Anda akan mendapatkan respon seperti ini:
{"ip":"50.78.253.58","country_code":"US","country_name":"United States", "region_code":"MA","region_name":"Massachusetts","city":"Boston", "zip_code":"02116","time_zone":"America/New_York","latitude":42.3496, "longitude":-71.0746,"metro_code":506}
Catatan, ada parameter jalur json dalam permintaan tersebut. Untuk mendapatkan respon dalam format XML atau CSV, Anda perlu menggantinya dengan format yang sesuai:
ip-api.com/xml/50.78.253.58
ip-api.com/csv/50.78.253.58
API dan Metode HTTP
Di bagian sebelumnya , kami melihat API, mengirimkan permintaan GET ke server untuk mendapatkan informasi. Ada empat cara utama (atau metode) untuk meminta informasi dari server web melalui HTTP:
- GET;
- POST;
- TARUH;
- MENGHAPUS.
Secara teknis, ada lebih dari empat jenis permintaan (misalnya, masih ada HEAD, OPTIONS, dan CONNECT), tetapi jarang digunakan di API dan kecil kemungkinan Anda akan menemukannya. Sebagian besar API terbatas pada empat metode ini, dan terkadang bahkan beberapa bagian darinya. Selalu ada API yang hanya menggunakan GET atau hanya GET dan POST.
GET adalah permintaan yang Anda gunakan saat mengunjungi situs dengan memasukkan alamatnya di bilah alamat browser Anda. Saat Anda mengunjungi ip-api.com/json/50.78.253.58 , Anda menggunakan metode GET. Permintaan ini dapat dianggap sebagai perintah: "Hai, server web, tolong beri saya informasi ini."
Permintaan GET, menurut definisi, tidak mengubah konten database server. Tidak ada yang disimpan dan tidak ada yang diubah. Informasinya hanya dibaca.
POST adalah permintaan yang digunakan saat mengisi formulir atau mengirimkan informasi, mungkin dimaksudkan untuk diproses oleh skrip server. Setiap kali Anda masuk ke situs, Anda membuat permintaan POST, memasukkan nama pengguna dan (mudah-mudahan) kata sandi terenkripsi. Dengan membuat permintaan POST melalui API, Anda memberi tahu server, "Mohon simpan informasi ini di database."
Permintaan PUT saat berinteraksi dengan situs lebih jarang digunakan, tetapi dari waktu ke waktu terjadi di API. Permintaan ini digunakan untuk mengubah suatu objek atau informasi. Misalnya, API dapat menggunakan permintaan POST untuk membuat pengguna dan permintaan PUT untuk mengubah alamat email mereka.
Permintaan DELETE, seperti yang Anda duga, digunakan untuk menghapus objek. Misalnya, jika Anda mengirim permintaan DELETE ke myapi.com/user/23 , ID pengguna 23 akan dihapus. Metode DELETE tidak sering ditemukan di API terbuka, karena metode ini terutama dibuat untuk mendistribusikan informasi atau untuk memungkinkan pengguna membuat atau mempublikasikan informasi, tetapi jangan menghapusnya dari database.
Tidak seperti GET, POST, PUT, dan DELETE, permintaan memungkinkan informasi untuk diteruskan dalam isi permintaan, selain URL atau rute dari mana data diminta.
Seperti respons yang diterima dari server web, data dalam isi permintaan ini biasanya JSON atau kurang umum XML. Format data spesifik ditentukan oleh sintaks API. Misalnya, saat menggunakan API yang menambahkan komentar ke postingan blog, Anda dapat membuat permintaan PUT berikut:
example.com/comments?post=123
dengan isi permintaan seperti ini:
{"title": "Great post about APIs!", "body": "Very informative. Really helped me out with a tricky technical challenge I was facing. Thanks for taking the time to write such a detailed blog post about PUT requests!", "author": {"name": "Ryan Mitchell", "website": "http://pythonscraping.com", "company": "O'Reilly Media"}}
Perhatikan bahwa ID entri blog (123) diteruskan sebagai parameter di URL, dan konten komentar yang kita buat diteruskan di badan permintaan. Parameter dan data dapat diteruskan baik di parameter maupun di badan permintaan. Parameter mana yang diperlukan dan ke mana mereka diteruskan - sekali lagi, ditentukan oleh sintaks API.
Selengkapnya Tentang Menanggapi Permintaan API
Seperti yang kita lihat di contoh ip-api.com di awal bab ini, fitur penting dari API adalah antarmuka ini mengembalikan respons yang diformat dengan baik. Format respons yang paling umum adalah XML (eXtensible Markup Language) dan JSON (JavaScript Object Notation).
Dalam beberapa tahun terakhir, JSON telah menjadi jauh lebih populer daripada XML karena beberapa alasan utama. Pertama, file JSON biasanya lebih kecil dari file XML yang dibuat dengan baik. Bandingkan, misalnya, data XML berikut ini yang terdiri dari 98 karakter:
<user><firstname>Ryan</firstname><lastname>Mitchell</
lastname><username>Kludgist</username></user>
Sekarang lihat data JSON yang sama:
{"user":{"firstname":"Ryan","lastname":"Mitchell","username":"Kludgist"}}
Itu hanya 73 karakter, 36% lebih kecil dari data XML yang sama.
Tentu saja, argumennya kemungkinan XML dapat diformat seperti ini:
<user firstname="ryan" lastname="mitchell" username="Kludgist"></user>
Namun, ini tidak disarankan karena tampilan ini tidak mendukung penumpukan data yang dalam. Namun, panjang entri tersebut adalah 71 karakter - hampir sama dengan JSON yang setara.
Alasan lain mengapa JSON menjadi lebih populer daripada XML begitu cepat berkaitan dengan perubahan teknologi web. Sebelumnya, penerima API sebagian besar adalah skrip sisi server PHP atau .NET. Sekarang mungkin ternyata kerangka kerja seperti Angular atau Backbone akan menerima dan mengirim panggilan API. Sampai batas tertentu, teknologi server tidak peduli bentuk data apa yang digunakan. Namun, pustaka JavaScript seperti Backbone merasa lebih mudah untuk menangani JSON.
Secara umum diterima bahwa API mengembalikan respons dalam format XML atau JSON, tetapi opsi lain apa pun dimungkinkan. Jenis respons API hanya dibatasi oleh imajinasi programmer yang membuat antarmuka ini. Format respons khas lainnya adalah CSV (seperti yang terlihat pada contoh dari ip-api.com). API terpisah bahkan memungkinkan Anda membuat file. Anda dapat mengirim permintaan ke server, yang akan menghasilkan gambar dengan teks tertentu yang ditumpangkan di atasnya, atau Anda dapat meminta file XLSX atau PDF tertentu.
Beberapa API tidak memberikan respons sama sekali. Misalnya, jika Anda mengirim permintaan ke server untuk membuat komentar di entri blog, itu hanya dapat mengembalikan kode respons HTTP 200, yang berarti: “Saya memposting komentar; semuanya baik-baik saja!" Kueri lain mungkin memberikan respons minimal seperti ini:
{"success": true}
Jika terjadi kesalahan, Anda bisa mendapatkan respons berikut:
{"error": {"message": "Something super bad happened"}}
Atau, jika API tidak dikonfigurasi dengan baik, Anda mungkin akan mendapatkan pelacakan tumpukan yang tidak dapat dibaca atau beberapa teks bahasa Inggris. Saat mengirim permintaan ke API, biasanya masuk akal untuk terlebih dahulu memverifikasi bahwa respons yang Anda terima memang dalam format JSON (atau XML, atau CSV, atau format apa pun yang ingin Anda terima).
tentang Penulis
Ryan Mitchell adalah Insinyur Perangkat Lunak Senior di HedgeServ, Boston, tempat dia mengembangkan API dan alat untuk analisis data. Ryan lulus dari Sekolah Tinggi Teknik dan Teknologi. Franklin V. Olin memegang gelar MSc dalam Rekayasa Perangkat Lunak dan Sertifikat dalam Analisis dan Pemrosesan Data dari program pendidikan berkelanjutan Universitas Harvard. Sebelum bergabung dengan HedgeServ, Ryan bekerja di Abine, tempat dia mengembangkan pencakar web dan alat otomatisasi dengan Python. Dia secara teratur memberi nasihat tentang proyek pengikisan web untuk ritel, keuangan, dan farmasi. Saat ini bekerja sebagai konsultan dan guru lepas di Northeastern University dan College of Engineering and Technology. Franklin V. Olin.
Rincian lebih lanjut tentang buku dapat ditemukan di situs web penerbit
» Daftar Isi
» Kutipan
Untuk Habitants diskon 25% untuk kupon - Python
Setelah pembayaran untuk versi kertas buku, e-book dikirim ke e -surat.