¡Hola, habitantes! Si la programación es como la magia, entonces el web scraping es una brujería muy poderosa. Al escribir un programa automatizado simple, puede enviar solicitudes a servidores web, solicitarles datos y luego analizarlos y extraer la información que necesita. La nueva edición ampliada del libro presenta no solo el web scraping, sino que también ayuda a recopilar cualquier tipo de datos en la Internet moderna. La Parte I se centra en la mecánica del web scraping: cómo usar Python para solicitar información de un servidor web, realizar el procesamiento básico de respuestas del servidor y organizar interacciones automatizadas con sitios. La Parte II explora herramientas y aplicaciones más específicas que resultan útiles en cualquier escenario de raspado web. - Analizar páginas HTML complejas.- Desarrollar robots de búsqueda utilizando el marco Scrapy. - Aprenda a almacenar datos extraídos. - Leer y extraer datos de documentos. - Limpiar y normalizar datos mal formateados. - Leer y escribir información en lenguajes naturales. - Dominar la búsqueda de formularios e inicios de sesión. - Aprenda el raspado de JavaScript y el trabajo de API. - Utilice y escriba programas para convertir imágenes a texto. - Aprenda a evitar las trampas de raspado y los bloqueadores de bots. - Pruebe su propio sitio web con scraping.- Aprenda el raspado de JavaScript y el trabajo de API. - Utilice y escriba programas para convertir imágenes a texto. - Aprenda a evitar las trampas de raspado y los bloqueadores de bots. - Pruebe su propio sitio web con scraping.- Aprenda el raspado de JavaScript y el trabajo de API. - Utilice y escriba programas para convertir imágenes a texto. - Aprenda a evitar las trampas de raspado y los bloqueadores de bots. - Pruebe su propio sitio web con scraping.
Rastreo web con API
JavaScript se considera tradicionalmente la maldición universal de los rastreadores web. Hace mucho tiempo, hubo momentos en los que podía estar seguro de que una solicitud que enviaba a un servidor web recibiría los mismos datos que un usuario vería en su navegador al realizar la misma solicitud.
A medida que proliferan los métodos JavaScript y Ajax para generar y cargar contenido, la situación descrita anteriormente se está volviendo menos común. En el Capítulo 11, vimos una forma de resolver este problema: usar Selenium para automatizar el navegador y obtener datos. Esto es fácil de hacer. Esto casi siempre funciona.
El problema es que cuando tiene un martillo tan poderoso y efectivo como el selenio en sus manos, cada tarea de raspado de telaraña comienza a sentirse como un clavo.
En este capítulo, aprenderá cómo, omitiendo todo este JavaScript (¡sin ejecutarlo ni siquiera cargarlo!), Puede acceder directamente a la fuente de datos: las API que generan esos datos.
Una breve introducción a la API
Hay innumerables libros, charlas y tutoriales sobre los matices de las API REST, GraphQL21, JSON y XML, pero todos se basan en un concepto simple. La API define una sintaxis estandarizada que permite que un programa interactúe con otro, incluso si están escritos en diferentes lenguajes o tienen diferentes estructuras.
Esta sección se centra en las API web (en particular, aquellas que permiten que el servidor web interactúe con el navegador), y aquí entendemos por API este tipo de interfaz. Pero puede tener en cuenta que en otros contextos, API también es un término genérico que puede significar, por ejemplo, una interfaz que permite que un programa Java interactúe con un programa Python que se ejecuta en la misma computadora. API no siempre significa "interfaz a través de Internet" y no necesita incluir ninguna tecnología web.
Los desarrolladores suelen utilizar las API web para interactuar con servicios de código abierto ampliamente publicitados y bien documentados. Por ejemplo, el canal de televisión de deportes por cable estadounidense ESPN proporciona una API (http://www.espn.com/apis/devcenter/docs/) para obtener información sobre atletas, puntajes de juegos, etc. Google tiene una sección para desarrolladores (https: / /console.developers.google.com) hay docenas de API para traducción de idiomas, análisis y geolocalización.
La documentación de todas estas API normalmente describe rutas o puntos finales en forma de URL que se pueden solicitar, con parámetros mutables, ya sea como parte de estas URL o actuando como parámetros GET.
Por ejemplo, en la siguiente URL, pathparam es un parámetro de ruta:
example.com/the-api-route/pathparam
Y aquí pathparam es el valor del parámetro param1:
example.com/the-api-route?param1=pathparam
Ambos métodos de transferencia de datos a la API se utilizan con bastante frecuencia, aunque, al igual que muchos otros aspectos de la informática, son objeto de acaloradas discusiones filosóficas sobre cuándo y dónde deben pasarse las variables a través de la ruta, y cuándo, a través de los parámetros.
La respuesta a una solicitud de API generalmente se devuelve en formato JSON o XML. Hoy en día, JSON es mucho más popular que XML, pero este último también se encuentra a veces. Muchas API le permiten elegir el tipo de respuesta, generalmente con otro parámetro que determina qué tipo de respuesta desea recibir.
A continuación, se muestra un ejemplo de una respuesta JSON a una solicitud de API:
{"user":{"id": 123, "name": "Ryan Mitchell", "city": "Boston"}}
Y aquí está la respuesta a la solicitud de la API en formato XML:
<user><id>123</id><name>Ryan Mitchell</name><city>Boston</city></user>
El sitio ip-api.com (http://ip-api.com/) tiene una API clara y conveniente que convierte las direcciones IP en direcciones físicas reales. Puede intentar
hacer una solicitud de API simple escribiendo lo siguiente ip-api.com/json/50.78.253.58 en su navegador,
y obtendrá una respuesta 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}
Tenga en cuenta que hay un parámetro de ruta json en la solicitud. Para obtener una respuesta en formato XML o CSV, debe reemplazarlo con el formato apropiado:
ip-api.com/xml/50.78.253.58
ip-api.com/csv/50.78.253.58
API y métodos HTTP
en la sección anterior , miramos la API, enviando una solicitud GET al servidor para obtener información. Hay cuatro formas (o métodos) principales de solicitar información de un servidor web a través de HTTP:
- GET;
- CORREO;
- PONER;
- ELIMINAR.
Técnicamente, hay más de cuatro tipos de solicitudes (por ejemplo, todavía hay HEAD, OPTIONS y CONNECT), pero rara vez se usan en la API y es poco probable que alguna vez los encuentre. La gran mayoría de las API se limitan a estos cuatro métodos y, a veces, incluso a una parte de ellos. Siempre hay API que usan solo GET o solo GET y POST.
OBTENER es la solicitud que utiliza cuando visita un sitio ingresando su dirección en la barra de direcciones de su navegador. Cuando visita ip-api.com/json/50.78.253.58 , está utilizando el método GET. Esta solicitud se puede considerar como un comando: "Hola, servidor web, por favor, dame esta información".
Una solicitud GET, por definición, no cambia el contenido de la base de datos del servidor. No se guarda nada y no se cambia nada. La información solo se lee.
POST es una solicitud que se utiliza al completar un formulario o enviar información, presumiblemente destinada a ser procesada por un script de servidor. Cada vez que inicia sesión en el sitio, realiza una solicitud POST, pasando un nombre de usuario y (con suerte) una contraseña cifrada. Al realizar una solicitud POST a través de la API, le está diciendo al servidor: "Guarde esta información en la base de datos".
La solicitud PUT al interactuar con sitios se usa con menos frecuencia, pero de vez en cuando ocurre en la API. Esta solicitud se utiliza para cambiar un objeto o información. Por ejemplo, la API puede usar una solicitud POST para crear un usuario y una solicitud PUT para cambiar su dirección de correo electrónico.
Las solicitudes DELETE, como puede adivinar, se utilizan para eliminar un objeto. Por ejemplo, si envía una solicitud DELETE a myapi.com/user/23 , se eliminará el ID de usuario 23. Los métodos DELETE no se encuentran a menudo en las API abiertas, ya que se crean principalmente para distribuir información o para permitir que los usuarios creen o publicar información, pero no eliminarla de las bases de datos.
A diferencia de las solicitudes GET, POST, PUT y DELETE permiten que se pase información en el cuerpo de la solicitud, además de la URL o ruta desde la que se solicitan los datos.
Al igual que la respuesta recibida del servidor web, estos datos en el cuerpo de la solicitud suelen ser JSON o, con menos frecuencia, XML. El formato de datos específico está determinado por la sintaxis de la API. Por ejemplo, cuando usa una API que agrega comentarios a las publicaciones de blog, puede crear la siguiente solicitud PUT:
example.com/comments?post=123
con un cuerpo de solicitud 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"}}
Tenga en cuenta que el ID de la publicación de blog (123) se pasa como un parámetro en la URL, y el contenido del comentario que creamos se pasa en el cuerpo de la solicitud. Los parámetros y los datos se pueden pasar tanto en el parámetro como en el cuerpo de la solicitud. Qué parámetros se requieren y dónde se pasan, nuevamente, está determinado por la sintaxis de la API.
Más sobre
cómo responder a las solicitudes de API Como vimos en el ejemplo de ip-api.com al comienzo de este capítulo, una característica importante de las API es que estas interfaces devuelven respuestas bien formateadas. Los formatos de respuesta más comunes son XML (eXtensible Markup Language) y JSON (JavaScript Object Notation).
En los últimos años, JSON se ha vuelto mucho más popular que XML por varias razones principales. En primer lugar, los archivos JSON suelen ser más pequeños que los archivos XML bien elaborados. Compare, por ejemplo, los siguientes datos XML que tienen 98 caracteres de longitud:
<user><firstname>Ryan</firstname><lastname>Mitchell</
lastname><username>Kludgist</username></user>
Ahora mire los mismos datos JSON:
{"user":{"firstname":"Ryan","lastname":"Mitchell","username":"Kludgist"}}
Eso es solo 73 caracteres, un 36% menos que los mismos datos XML.
Por supuesto, es probable que el argumento de que XML se pueda formatear así:
<user firstname="ryan" lastname="mitchell" username="Kludgist"></user>
Sin embargo, esto no se recomienda porque esta vista no admite el anidamiento profundo de datos. Aún así, la entrada tiene 71 caracteres, aproximadamente lo mismo que el JSON equivalente.
Otra razón por la que JSON se está volviendo más popular que XML tiene que ver con los cambios en las tecnologías web. Anteriormente, los destinatarios de la API eran principalmente scripts del lado del servidor PHP o .NET. Ahora bien, puede resultar que un marco como Angular o Backbone reciba y envíe llamadas a la API. Hasta cierto punto, a las tecnologías de servidor no les importa la forma que adopten los datos. Sin embargo, a las bibliotecas de JavaScript como Backbone les resulta más fácil manejar JSON.
En general, se acepta que las API devuelven una respuesta en formato XML o JSON, pero es posible cualquier otra opción. El tipo de respuesta de la API está limitado solo por la imaginación del programador que creó esta interfaz. Otro formato de respuesta típico es CSV (como se ve en el ejemplo de ip-api.com). Las API independientes incluso le permiten crear archivos. Puede enviar una solicitud al servidor, que generará una imagen con el texto especificado superpuesto, o puede solicitar un archivo XLSX o PDF específico.
Algunas API no devuelven ninguna respuesta. Por ejemplo, si envía una solicitud al servidor para crear un comentario en una publicación de blog, solo puede devolver un código de respuesta HTTP de 200, lo que significa: “Publiqué un comentario; ¡todo esta bien!" Otras consultas pueden devolver una respuesta mínima como esta:
{"success": true}
En caso de error, puede obtener una respuesta como esta:
{"error": {"message": "Something super bad happened"}}
Alternativamente, si la API no está bien configurada, puede terminar con un seguimiento de pila indescifrable o algún texto en inglés. Al realizar una solicitud a una API, generalmente tiene sentido verificar primero que la respuesta que recibe está en formato JSON (o XML, o CSV, o cualquier formato que espere recibir).
Sobre el Autor
Ryan Mitchell es ingeniera de software senior en HedgeServ, Boston, donde desarrolla API y herramientas para el análisis de datos. Ryan se graduó de la Facultad de Ingeniería y Tecnología. Franklin V. Olin tiene una Maestría en Ingeniería de Software y un Certificado en Análisis y Procesamiento de Datos de los cursos de educación continua de la Universidad de Harvard. Antes de unirse a HedgeServ, Ryan trabajó en Abine, donde desarrolló web scrapers y herramientas de automatización en Python. Asesora regularmente en proyectos de web scraping para minoristas, finanzas y productos farmacéuticos. Al mismo tiempo trabaja como consultor y profesor independiente en Northeastern University y la Facultad de Ingeniería y Tecnología. Franklin V. Olin.
Se pueden encontrar más detalles sobre el libro en el sitio web de la editorial
» Tabla de contenido
» Extracto
para los habitantes un 25% de descuento en el cupón - Python
Tras el pago de la versión impresa del libro, se envía un libro electrónico a e -correo.