¿Cuál sería la forma más ética de consumir contenido de un sitio que no proporciona una API?

Question

Me preguntaba cuál sería la forma más ética de consumir algunos bytes (386 precisamente) del contenido de un determinado Sitio A, con una aplicación (por ejemplo, Google App Engine) en algún sitio B, pero hacerlo bien , sin raspado intencionado, realmente solo necesito verificar el estado de un servicio público y actualmente no están proporcionando ninguna API. Así que el marcado en Sitio A tiene una matriz de JavaScript con la información que necesito y poder acceder a ella, digamos que una vez cada cinco minutos sería suficiente.

Cualquier consejo será muy apreciado.

ACTUALIZACIÓN:

En primer lugar todos muchas gracias por los comentarios. El sitio A es básicamente el sitio web de la compañía que actualmente opera nuestra red pública de metro, así que estoy planeando desarrollar una pequeña aplicación gratuita para Android para que cualquiera tenga no solo un mapa con toda la red y sus estaciones, sino también información actualizada sobre la disponibilidad del servicio (y esos son los bytes que eventualmente voy a consumir), etcétera.

Answer 1

Habrá algunos puntos muy diferentes de vista, pero es de esperar que aquí es un poco de alimento para el pensamiento:

1. Pregunta al propietario del sitio en primer lugar, si saben de antemano que son menos propensos a ser molesto.
2. Es el contenido en Sitio A accesible en una parte pública del sitio, p. sin la necesidad de iniciar sesión?
3. Si la respuesta al # 2 es que es contenido público, entonces no vería un problema, ya que raspar el sitio para esa información no es realmente diferente que apuntar tu navegador al sitio y leerlo por ti mismo.
4. Por supuesto, la respuesta al # 3 depende de cómo se monetiza el sitio. Si Sitio A proporciona publicidad para generar ingresos para el sitio, entonces no sería una idea comenzar a raspar contenido, ya que estaría pasando por alto cómo el sitio genera dinero.

Creo que lo más importante que hacer, es hablar con el propietario del sitio en primer lugar, y determinar directamente de ellos si:

1. ¿Está bien que yo sea utilices los contenidos de su sitio.
2. Tienen una API en la tubería (simplemente resaltar el deseo puede llevarlos a considerarlo).

Sólo mi punto de vista ...

Answer 2

Update (4 años después): La pregunta abarca específicamente el lado ético del problema. Es por eso que esta vieja respuesta está escrita de esta manera.

Normalmente, en tal situación, póngase en contacto con ellos.

Si no les gusta, entonces éticamente no puede hacerlo (legalmente es otra historia, dependiendo de si se proporciona una licencia en el sitio o no. ¿Qué inicio de sesión/anonimato u otras restricciones tienen para acceder? tiene que usar datos de prueba/falso, etc. ...).

Si lo permiten, pueden proporcionar una API (pueden implicar costos; usted tendrá que determinar cuánto vale el efecto para su aplicación), o prometer algún tipo de comportamiento esperado para usted, que podría serlo estar desechando, o cualquier otra opción que decidan.

Si lo permiten pero no están listos para ayudar a que sea más fácil, raspar (con sus otros inconvenientes aún aplicables) será correcto, al menos "éticamente".

Answer 3

No lo tocaría salvo para enviar un correo electrónico al administrador del sitio y obtener su permiso por escrito. Dicho esto: si consume el contenido sin extraer valor más allá del valor que recibe un solo usuario al observar los datos que necesita de ellos, es discutible que cualquier TOU que tengan no lo encuentre en violación. Sin embargo, si obtiene un valor notable más allá de qué obtendría un solo usuario de los datos que necesita de su sitio, es decir, si usa los datos , sus resultados terminan proporcionando valor a 100x de los usuarios de su propio sitio. Diría que necesita permiso expreso para hacerlo, para dormir bien por la noche.

Sin embargo, todo está desactivado si la información ya está en el dominio público (y puede probarlo), o los datos que necesita de ellos están bajo algún tipo de "licencia abierta" como la de GNU.

Por otra parte, la web no es nada sin enlaces al contenido de los demás. Todos capturamos y volvemos a publicar en varios foros, por ejemplo, leemos un artículo sobre CNN y luego comenzamos a comentarlo en un foro en línea, , tal vez citemos el artículo y le proporcionamos un enlace. Solo depende de cuán flexible sea y de mente abierta el administrador y el propietario del sitio. Pero, en realidad, para evitar ser demandado (si empuja el viene) pediría permiso.

Answer 4

"sin raspado intencionado": tiene la intención de raspar. =)

Las razones basadas en la ética razonable no hay que tomarlo de su página web es:

1. Es posible que quieran mostrar anuncios o avisos de seguridad importantes para los usuarios
2. Esto puede hacer que sus estadísticas inexactas

En términos de martilleo de su sitio, probablemente no sea un problema. Pero si lo es:

• Probablemente desee raspar la cantidad mínima necesaria (por ejemplo, haga la mínima cantidad de solicitudes HTTP), y no golpee el servidor con demasiada frecuencia.
• Probablemente no desee que todas sus aplicaciones consulten el sitio web; podría tener su propio sitio web consultarlos a través de un cronjob. Esto le permitirá un mejor control en caso de que cambie su formato, o le permitirá lanzar errores de "servicio actualmente no disponible" a sus usuarios, simplemente cambiando su sitio web; introduce otro punto de falla, pero probablemente valga la pena. De esta forma, si hay un error, las personas no necesitan actualizar sus aplicaciones.

Pero lo mejor que puedes hacer es hablar con el sitio web, preguntándoles qué es lo mejor. Es posible que tengan una API oculta que le permitirían usar y que tal vez haya permitido que otras personas también la utilicen.

Answer 5

1. Use un user-agent encabezado que identifica su servicio.
2. Compruebe su robots.txt (y vuelva a verificarlo a intervalos regulares, por ejemplo, diariamente).
3. Respete cualquier Disallow en un registro que coincida con su agente de usuario (be liberal al interpretar el nombre). Si no hay registro para su agente de usuario, use el registro para User-agent: *.
4. Respete el (no estándar) Crawl-delay, que le indica cuántos segundos debe esperar antes de volver a solicitar un recurso de ese host.