Olá, Habitantes! Se programar é como mágica, então web scraping é uma feitiçaria muito poderosa. Ao escrever um programa automatizado simples, você pode enviar solicitações para servidores da web, solicitar dados deles e, em seguida, analisá-los e extrair as informações de que precisa. A nova edição estendida do livro apresenta não apenas web scraping, mas também ajuda a coletar qualquer tipo de dados na Internet moderna. A Parte I concentra-se na mecânica de web scraping: como usar Python para solicitar informações de um servidor web, executar o processamento básico de resposta do servidor e organizar interações automatizadas com sites. A Parte II explora ferramentas e aplicativos mais específicos que são úteis em qualquer cenário de web scraping. - Analise páginas HTML complexas.- Desenvolver robôs de busca usando o framework Scrapy. - Aprenda como armazenar dados extraídos. - Ler e extrair dados de documentos. - Limpe e normalize dados mal formatados. - Ler e escrever informações em línguas naturais. - Domine a pesquisa de formulários e logins. - Aprenda scraping de JavaScript e trabalho de API. - Use e escreva programas para converter imagens em texto. - Aprenda a contornar armadilhas de raspagem e bloqueadores de bots. - Teste seu próprio site com raspagem.- Aprenda scraping de JavaScript e trabalho de API. - Use e escreva programas para converter imagens em texto. - Aprenda a contornar armadilhas de raspagem e bloqueadores de bots. - Teste seu próprio site com raspagem.- Aprenda scraping de JavaScript e trabalho de API. - Use e escreva programas para converter imagens em texto. - Aprenda a contornar armadilhas de raspagem e bloqueadores de bots. - Teste seu próprio site com raspagem.
Rastreamento da web com API
JavaScript é tradicionalmente considerado a maldição universal dos rastreadores da web. Há muito tempo, você podia ter certeza de que uma solicitação enviada a um servidor da web receberia os mesmos dados que um usuário veria em seu navegador ao fazer a mesma solicitação.
À medida que os métodos JavaScript e Ajax para gerar e carregar conteúdo proliferam, a situação descrita acima está se tornando menos comum. No Capítulo 11, vimos uma maneira de resolver esse problema: usando o Selenium para automatizar o navegador e buscar dados. Isso é fácil de fazer. Isso quase sempre funciona.
O problema é que, quando você tem um martelo tão poderoso e eficaz quanto o selênio em suas mãos, toda tarefa de raspar teia começa a parecer um prego.
Neste capítulo, você aprenderá como, ignorando todo esse JavaScript (sem executá-lo ou mesmo carregá-lo!), Você pode acessar diretamente a fonte de dados - as APIs que geram esses dados.
Uma breve introdução à API
Existem inúmeros livros, palestras e tutoriais sobre as nuances das APIs REST, GraphQL21, JSON e XML, mas todos são baseados em um conceito simples. A API define uma sintaxe padronizada que permite que um programa interaja com outro, mesmo que sejam escritos em linguagens diferentes ou tenham estruturas diferentes.
Esta seção se concentra em APIs da web (em particular aquelas que permitem que o servidor da web interaja com o navegador), e aqui entendemos por API esse tipo de interface. Mas você pode ter em mente que em outros contextos, API também é um termo genérico que pode significar, por exemplo, uma interface que permite a um programa Java interagir com um programa Python em execução no mesmo computador. API nem sempre significa "interface na Internet" e não precisa incluir nenhuma tecnologia da web.
As APIs da Web são mais comumente usadas por desenvolvedores para interagir com serviços de código aberto amplamente anunciados e bem documentados. Por exemplo, o canal de TV americano de esportes a cabo ESPN fornece uma API (http://www.espn.com/apis/devcenter/docs/) para informações sobre atletas, placares de jogos etc. O Google tem uma seção de desenvolvedores (https: / /console.developers.google.com), existem dezenas de APIs para tradução, análise e geolocalização de idiomas.
A documentação para todas essas APIs geralmente descreve rotas ou terminais na forma de URLs que podem ser solicitados, com parâmetros mutáveis, como parte desses URLs ou atuando como parâmetros GET.
Por exemplo, no seguinte URL, pathparam é um parâmetro de caminho:
example.com/the-api-route/pathparam
E aqui pathparam é o valor do parâmetro param1:
example.com/the-api-route?param1=pathparam
Ambos os métodos de transferência de dados para a API são usados amplamente, embora, como muitos outros aspectos da ciência da computação, estão sujeitos a acaloradas discussões filosóficas sobre quando e onde as variáveis devem ser passadas por meio de caminhos e quando - por meio de parâmetros.
A resposta a uma solicitação de API geralmente é retornada no formato JSON ou XML. Hoje em dia, JSON é muito mais popular do que XML, mas o último também é encontrado às vezes. Muitas APIs permitem que você escolha o tipo de resposta, geralmente com outro parâmetro que determina o tipo de resposta que você deseja receber.
Aqui está um exemplo de uma resposta JSON a uma solicitação de API:
{"user":{"id": 123, "name": "Ryan Mitchell", "city": "Boston"}}
E aqui está a resposta à solicitação da API em formato XML:
<user><id>123</id><name>Ryan Mitchell</name><city>Boston</city></user>
O site ip-api.com (http://ip-api.com/) possui uma API clara e conveniente que converte endereços IP em endereços físicos reais. Você pode tentar
fazer uma solicitação de API simples digitando o seguinte ip-api.com/json/50.78.253.58 em seu navegador
e obterá uma resposta como esta:
{"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}
Observe que há um parâmetro de caminho json na solicitação. Para obter uma resposta no formato XML ou CSV, você precisa substituí-la pelo formato apropriado:
ip-api.com/xml/50.78.253.58
ip-api.com/csv/50.78.253.58
Métodos API e HTTP
na seção anterior , olhamos a API, enviando uma solicitação GET ao servidor para obter informações. Existem quatro formas (ou métodos) principais de solicitar informações de um servidor web via HTTP:
- GET;
- PUBLICAR;
- COLOCAR;
- DELETE.
Tecnicamente, existem mais de quatro tipos de solicitações (por exemplo, ainda há HEAD, OPTIONS e CONNECT), mas raramente são usados na API e é improvável que você os encontre. A grande maioria das APIs é limitada a esses quatro métodos e, às vezes, até mesmo a parte deles. Sempre há APIs que usam apenas GET ou apenas GET e POST.
GET é a solicitação que você usa quando visita um site digitando seu endereço na barra de endereço do seu navegador. Ao visitar ip-api.com/json/50.78.253.58 , você está usando o método GET. Essa solicitação pode ser considerada um comando: "Ei, servidor da web, por favor, dê-me esta informação."
Uma solicitação GET, por definição, não altera o conteúdo do banco de dados do servidor. Nada é salvo e nada é alterado. A informação é apenas lida.
POST é uma solicitação usada ao preencher um formulário ou enviar informações, presumivelmente destinadas ao processamento por um script de servidor. Cada vez que você entra no site, você faz uma solicitação POST, passando um nome de usuário e (espero) uma senha criptografada. Ao fazer uma solicitação POST por meio da API, você está dizendo ao servidor: "Salve essas informações no banco de dados".
A solicitação PUT ao interagir com sites é usada com menos frequência, mas de vez em quando ocorre na API. Esta solicitação é usada para alterar um objeto ou informação. Por exemplo, a API pode usar uma solicitação POST para criar um usuário e uma solicitação PUT para alterar seu endereço de e-mail.
Solicitações DELETE, como você pode imaginar, são usadas para excluir um objeto. Por exemplo, se você enviar uma solicitação DELETE para myapi.com/user/23 , o ID do usuário 23 será excluído. Os métodos DELETE não são frequentemente encontrados em APIs abertas, pois são criados principalmente para distribuir informações ou permitir que os usuários criem ou publique informações, mas não as remova dos bancos de dados.
Ao contrário das solicitações GET, POST, PUT e DELETE permitem que informações sejam passadas no corpo da solicitação, além da URL ou rota a partir da qual os dados são solicitados.
Como a resposta recebida do servidor da web, esses dados no corpo da solicitação geralmente são JSON ou, menos comumente, XML. O formato de dados específico é determinado pela sintaxe da API. Por exemplo, ao usar uma API que adiciona comentários às postagens do blog, você pode criar a seguinte solicitação PUT:
example.com/comments?post=123
com um corpo de solicitação como este:
{"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"}}
Observe que o ID da postagem do blog (123) é passado como um parâmetro no URL e o conteúdo do comentário que criamos é passado no corpo da solicitação. Parâmetros e dados podem ser transmitidos tanto no parâmetro quanto no corpo da solicitação. Quais parâmetros são necessários e onde são passados - novamente, é determinado pela sintaxe da API.
Mais sobre como responder a solicitações de API
Como vimos no exemplo ip-api.com no início deste capítulo, um recurso importante das APIs é que essas interfaces retornam respostas bem formatadas. Os formatos de resposta mais comuns são XML (eXtensible Markup Language) e JSON (JavaScript Object Notation).
Nos últimos anos, JSON se tornou muito mais popular do que XML por vários motivos principais. Primeiro, os arquivos JSON geralmente são menores do que os arquivos XML bem elaborados. Compare, por exemplo, os seguintes dados XML com 98 caracteres:
<user><firstname>Ryan</firstname><lastname>Mitchell</
lastname><username>Kludgist</username></user>
Agora observe os mesmos dados JSON:
{"user":{"firstname":"Ryan","lastname":"Mitchell","username":"Kludgist"}}
São apenas 73 caracteres, surpreendentes 36% menos do que os mesmos dados XML.
Obviamente, o argumento provavelmente é que o XML pode ser formatado assim:
<user firstname="ryan" lastname="mitchell" username="Kludgist"></user>
No entanto, isso não é recomendado porque essa visualização não oferece suporte a aninhamento de dados profundo. Ainda assim, a entrada tem 71 caracteres - quase o mesmo que o JSON equivalente.
Outra razão pela qual JSON está se tornando mais popular do que XML tão rapidamente tem a ver com as mudanças nas tecnologias da web. Anteriormente, os destinatários da API eram principalmente scripts do lado do servidor PHP ou .NET. Agora pode acontecer que uma estrutura como Angular ou Backbone receba e envie chamadas de API. Até certo ponto, as tecnologias de servidor não se importam com a forma que os dados assumem. No entanto, bibliotecas JavaScript como o Backbone acham mais fácil lidar com JSON.
É geralmente aceito que as APIs retornem uma resposta no formato XML ou JSON, mas qualquer outra opção é possível. O tipo de resposta da API é limitado apenas pela imaginação do programador que criou esta interface. Outro formato de resposta típico é CSV (conforme visto no exemplo de ip-api.com). APIs separadas permitem até mesmo criar arquivos. Você pode enviar uma solicitação ao servidor, que irá gerar uma imagem com o texto especificado sobreposto a ela, ou você pode solicitar um arquivo XLSX ou PDF específico.
Algumas APIs não retornam nenhuma resposta. Por exemplo, se você enviar uma solicitação ao servidor para criar um comentário em uma postagem do blog, ele só poderá retornar um código de resposta HTTP 200, o que significa: “Eu postei um comentário; tudo está bem!" Outras consultas podem retornar uma resposta mínima como esta:
{"success": true}
Em caso de erro, você pode obter a seguinte resposta:
{"error": {"message": "Something super bad happened"}}
Como alternativa, se a API não estiver bem configurada, você pode acabar com um rastreamento de pilha indecifrável ou algum texto em inglês. Ao enviar uma solicitação a uma API, geralmente faz sentido primeiro verificar se a resposta que você recebe está realmente no formato JSON (ou XML, ou CSV, ou qualquer formato que você espera receber).
Sobre o autor
Ryan Mitchell é engenheira de software sênior na HedgeServ, Boston, onde desenvolve APIs e ferramentas para análise de dados. Ryan se formou na Faculdade de Engenharia e Tecnologia. Franklin V. Olin possui um MSc em Engenharia de Software e um Certificado em Análise e Processamento de Dados pelos cursos de educação continuada da Universidade de Harvard. Antes de ingressar na HedgeServ, Ryan trabalhou na Abine, onde desenvolveu web scrapers e ferramentas de automação em Python. Ele regularmente dá consultoria em projetos de web scraping para varejo, finanças e produtos farmacêuticos. Paralelamente, trabalha como consultor e professor autônomo na Northeastern University e na Faculdade de Engenharia e Tecnologia. Franklin V. Olin.
Mais detalhes sobre o livro podem ser encontrados no site da editora
» Índice
» Trecho
Para Habitantes desconto de 25% no cupom - Python
Mediante o pagamento da versão em papel do livro, é enviado um e-book para o e -correspondência.