Cgeo: API de geocaching.com

Creado en 12 ago. 2011  ·  46Comentarios  ·  Fuente: cgeo/cgeo

¿Alguien ha comenzado alguna vez a trabajar en una implementación que haga uso de la nueva API de Groundspeak?
¿Al menos alguien pidió la documentación de la API y vio cuánto esfuerzo probablemente tomaría cambiar a la nueva API?
De lo contrario, me ofrecería a ponerme en contacto con Groundspeak y echar un vistazo a la documentación para tratar de hacer una estimación aproximada de la cantidad de cambios que implicaría un cambio.

Feature Request

Comentario más útil

Bueno, Groundspeak mostró cierta voluntad de discutir estos temas no técnicos y ya dimos algunas propuestas. Sin embargo, para seguir discutiendo esto, probablemente necesitemos ver el impacto/la diferencia entre el uso de la API y la implementación actual en el flujo de uso.

Preferiría no proporcionar ningún detalle en este foro abierto, sin embargo, seguramente incluiremos en esta discusión a cualquiera que esté dispuesto a trabajar en la implementación de la API, además de involucrar a nuestros usuarios antes de una decisión final.

Todos 46 comentarios

Esto, por supuesto, tendría que ser coordinado con #9...

donde esta la nueva api?? Creo que si hay una API que admita todas las funciones, deberíamos usarla. (pero solo si Groundspeak cambia la API inmediatamente si hacen una actualización en geocaching.com)

Api está disponible solo para aplicaciones seleccionadas. Cgeo era uno, cgeo opensource no lo es

Espero que no cambien la API con cada cambio en las páginas web...
De lo contrario, podríamos seguir rastreando las páginas y actualizar nuestro código con cada cambio que GC.com implemente en sus páginas web...
Leí que la API ahora estará disponible tanto para miembros premium como básicos con algunas limitaciones para miembros básicos.
Si no le importa, me pondré en contacto con Ryan en Groundspeak y le pediré la documentación de la API.
Florián.

Tenemos doc, no tenemos clave de acceso api

Leí la notificación sobre la próxima Api hace algunas semanas. ¿Alguien tiene más consejos?

:( Quise decir que actualizan la biblioteca después de los cambios en gc.com :D

Entonces, si no le importa, le pediría a Groundspeak una clave de acceso a la API para c-geo (y también aclararía con Groundspeak que c-geo-opensource es básicamente lo mismo que c-geo con solo una aclaración sobre la licencia de código abierto ).
¿Puede enviarme una copia de la documentación o, si está en algún lugar de la web, darme un enlace?
Florián.

Sammy se comunicó. Esperemos por el

Los contacté hace unas semanas. La respuesta fue una línea que me decía que les enviara una solicitud para acceder a la API. Parece que no hay documentación pública, necesita una clave API para la aplicación y cada usuario debe obtener una clave a través de un procedimiento OAuth. Y lo llaman "API pública"...

Creo que no deberíamos codificarlo. Será más fácil con el conector-interfaz para que no importe si importamos desde spidering, API, OC, gpx, web2cgeo...

Absolutamente. No pensé en la autenticación OAuth cuando pensé en cambiar sucesivamente a la nueva API.

@SammysHP : Alicia en el país de las maravillas de Groundsheep:

"Cuando uso una palabra", dijo Humpty Dumpty en un tono más bien desdeñoso, "significa exactamente lo que elijo que signifique, ni más ni menos".
"La pregunta es", dijo Alicia, "si puedes hacer que las palabras signifiquen tantas cosas diferentes".
"La pregunta es", dijo Humpty Dumpty, "quién será el amo, eso es todo".

Ayer recibí un correo de Groundspeak:

Estimado Sven,

Gracias por su paciencia mientras avanzamos con el Programa API de Geocaching.com. Se adjuntan dos documentos para que los revise. Devuélvame el formulario de inscripción de API completo y le enviaremos una clave de prueba de API.

El objetivo de este programa de API pública es permitir que terceros de confianza desarrollen aplicaciones y servicios utilizando el conjunto de datos de geocaching.com que atenderá principalmente a los miembros Premium de Groundspeak, al mismo tiempo que permite que se brinde una cantidad significativa de servicios a los miembros básicos. La API se proporcionará libre de regalías, para que los desarrolladores puedan generar ingresos (o no) según lo consideren oportuno, sin tener que pagar regalías a Groundspeak por el acceso a los datos.

Creemos que esto le brindará la capacidad de brindar un mejor servicio a la comunidad en general, incluidos los nuevos usuarios, al tiempo que brinda oportunidades adicionales para que los miembros básicos se actualicen a los servicios Premium completos. Idealmente, nos gustaría que los miembros que disfrutan de las experiencias introductorias se actualicen a la Membresía Premium para tener acceso completo a la aplicación/servicio. Los detalles específicos con respecto a esta estructura están contenidos en el Anexo A del Acuerdo. Se requerirá un acuerdo con los Términos y un Formulario de inscripción API completo antes del acceso a la base de datos de producción y el lanzamiento formal.

Tenga en cuenta que, como desarrollador de confianza, esperamos que no abuse de la API, ni en la puesta en escena ni en la producción. No se permite extraer datos del sitio web de geocaching.com en ninguna aplicación o servicio para miembros básicos o premium. En lugar de permitir el raspado, preferiríamos desarrollar llamadas API para satisfacer las necesidades específicas de los desarrolladores. Si tiene alguna pregunta sobre las posibles acciones que planea realizar con la API, publíquelas en los foros de la API y haremos todo lo posible para aclarar las reglas.

Se requerirá un inicio de sesión a través de Oauth para todos los usuarios de las aplicaciones/servicios habilitados para API. Después de recibir su formulario de inscripción de API completo, le enviaremos una clave de prueba para que acceda al servidor de prueba. Luego, después de revisar su producto y funcionalidad, avanzaremos con la clave API de producción.

Gracias de nuevo. Tenemos muchas ganas de trabajar con usted.

Atentamente,

cristian

cristian lutero
Gerente de Desarrollo de Negocios
Groundspeak, Inc.
Groundspeak - El idioma de la ubicación
www.groundspeak.com
www.geocaching.com

Aquí está el acuerdo de licencia de la API: http://www.file-upload.net/download-3675937/Groundspeak-API-License-Agreement-17-08-2011.pdf.html

El problema es que la clave debe ser pública ya que cada desarrollador compila su propia compilación (para probar y usar). Y por lo que he oído, eso es un problema para Groundspeak.
Entonces, mi sugerencia: espere hasta que se realice la interfaz del conector y luego desarrolle el uso de la API como una aplicación separada.

Hola, hojeé brevemente el acuerdo de licencia. Si bien no veo una solicitud explícita de confidencialidad con respecto a la clave API que quizás se derive de 4.17 o 4.18.
Lo que elimina el concepto de un conector externo es probablemente 4.16 (trabajo derivado) y 5.3 (usuarios finales, no otras aplicaciones).
Integrarlo en c:geo violaría 4.14.
Los límites básicos de miembros son una broma.
Voto por simplemente ignorarlo hasta que presenten un modelo de licencia sensato.

Creo que está bien pegar un correo que alguien recibió de Bryan:

Hola _________,

Estamos dispuestos a proporcionar acceso API a CGeo Opensource. Sin embargo, dado que la clave de licencia solo debe usarse para la aplicación individual, nos preocupa que pueda compartirse públicamente. Si se comparte públicamente, podría ser utilizado por otras aplicaciones y eso haría que Groundspeak se viera obligado a cancelar la clave específica. Esto, por supuesto, rompería la aplicación porque no podría acceder a los datos.

Entonces, ¿puede ayudarme a comprender cómo planea limitar el acceso a la clave de autenticación? No se puede divulgar públicamente bajo ninguna circunstancia. Dado que hay varios desarrolladores trabajando en el proyecto Opensource, sabemos que solo se necesita un desarrollador para proporcionar el código de forma externa y luego todos tendremos un problema. Proporcione toda la información que pueda y estaremos encantados de trabajar directamente con usted, o con el representante principal del proyecto, para que esto funcione.

Incluí a Christy Luther en este correo electrónico ya que ella está administrando el proceso de desarrollo para desarrolladores externos.

¡Gracias!

Atentamente,

bryan

Entonces están dispuestos a ayudarnos, pero también mi opinión es esperar hasta (para una mejor integración, una licencia menos estricta, tal vez una API que no necesite una clave, sino solo la clave OAuth).

lo que me deslumbra: Google es capaz de administrar tales modelos de desarrollo para su api de mapas. ¿Pero las ovejas de tierra no pueden? Extraño.

Hay dos cosas con Google:

  • La API de Google verifica el certificado, con eso se firma la aplicación. La clave de Groundspeak debería funcionar con todas las plataformas y lenguajes de programación.
  • La clave API de Google es gratuita, por lo que todos los desarrolladores pueden obtener una.

Sé. Es el proceso de api de Groundsheep el que está causando problemas aquí a medida que chocan diferentes culturas: el rígido "fuera de mi cancha" de St Jeremy y el bazar abierto, donde Google es fuerte. No podría tener más contraste. En cuanto a la parte dependiente de Android: si no recuerdo mal, también puede usar Google Maps desde aplicaciones web de JavaScript, por lo que parece que tienen un método independiente de la plataforma. Es la mentalidad diferente entre Google y Groundsheep lo que causa los contratiempos, Google no es malo, pero ¿qué es Groundsheep?

AFAIK, la clave para JavaScript verifica el dominio.

Eche otro vistazo, esta vez a la infraestructura de OSM: necesitan operar en un entorno abierto, pero proyectar su base de datos contra el mal uso. No verifican las aplicaciones para editar datos de OSM: ¿cómo debería funcionar esto? Con cada nuevo lanzamiento, parche, etcétera... ¿St Jeremy quiere volver a revisar todas las aplicaciones? ¿Controlar la neurosis, alguien? Entonces, OSM verifica a los usuarios. No parece ser un problema. Tal vez me estoy perdiendo algo, pero entonces, ¿por qué el modelo OSM no funcionaría para los datos de geocaching?

Estos fueron mis pensamientos cuando me enteré de la nueva API pública.

El problema con la clave API podría resolverse si cada desarrollador obtiene su propia clave, pero al observar las limitaciones para los miembros básicos, voto en contra del uso de la API.

BFKC está en contacto con Groundspeak, así que esperemos. Además, la única posibilidad de implementar la API es un conector como el de GeOrg: http://android.ranitos.de/files/connector-sample.zip Me gusta la forma en que se utiliza para la comunicación entre la aplicación y el conector.

Mientras tanto, puede enviarme un mensaje privado si desea un enlace a la documentación de la API.

Cerrando esto por el momento, lo tendremos en cuenta y volveremos a hablar de ello cuando se implemente la interfaz del conector. Ver #10

El usuario final podría ser responsable de ingresar una clave de usuario válida en c:geo. Los desarrolladores pueden desarrollar cada uno con su propia clave de usuario.

No, OAuth requiere una clave secreta para la aplicación.

Sí, una clave secreta para generar una clave de usuario. Luego, la clave de usuario se usa para comunicarse con el servidor API. Cómo / dónde el usuario obtiene la clave depende de ellos.

¿Dices que deberíamos usar la cuenta de otra aplicación para nuestros propósitos?

¿Cuál es el problema si solo un desarrollador obtiene la clave?
Tiene que haber alguien que sea responsable de publicar los lanzamientos "oficiales" en la tienda de Google.
Entonces, este desarrollador agregaría la clave API en algún archivo de configuración que se empaqueta en el apk.
Si otros desarrolladores quieren trabajar en la parte API del código, ¡ellos mismos pueden solicitar el acceso a la API!
Las personas que quieran usar versiones personalizadas de c:geo obviamente necesitarán su propia clave API, pero creo que la mayoría de los usuarios no quieren usar versiones personalizadas. En todos los casos, ¡esto sería mejor que ningún soporte de API!

La cuestión de la clave es sólo un problema menor. El problema principal es que, de acuerdo con los términos de licencia de Groundspeak, no debe obtener cachés en su aplicación por otros medios que no sean la API.
Eso significaría que teníamos que construir toda la funcionalidad en torno a la API, haciendo de c:geo efectivamente una aplicación Premium.

Bueno, una breve actualización sobre este tema.

Estimados usuarios,

Como algunos de ustedes saben, intentamos brindar servicio para miembros básicos y premium con la misma limitación. Por lo tanto, violamos el Acuerdo de licencia de API de Geocaching para miembros básicos. Lamentablemente, Groundspeak, Inc. (la empresa que se encarga del sitio Geocaching.com) detectó nuestras acciones y nos vimos obligados a suspender temporalmente la distribución de nuestra aplicación en Google Play y otras tiendas de aplicaciones. Algunos de ustedes probablemente tuvieron problemas con un inicio de sesión en los últimos días que pueden estar relacionados con eso.

Después de pensar durante mucho tiempo, decidimos legalizar nuestra aplicación, pero lamentablemente afecta a los miembros básicos. Debido a que los miembros básicos están limitados a descargar tres Geocachés completos por día según este acuerdo de licencia. Esta fue la razón por la que hicimos lo que hicimos antes. Para los miembros premium, el límite será el mismo que antes, 6 000 Geocachés por día.

La adaptación a las nuevas reglas llevará varios días debido a la adición de cuadros de diálogo de confirmación para los miembros básicos que requiere este acuerdo de licencia. Espero que lancemos una nueva versión lo antes posible, incluso a costa de traducciones incompletas.

Equipo de desarrollo de Geocaching4Locus

Suponiendo que c:geo pueda obtener acceso a la API desde Groundspeak:

  1. ¿Qué puntos del acuerdo de licencia de API existente necesitarían ser discutidos y/o modificados para cumplir con nuestros requisitos?
  2. ¿Podemos mantener todas las funciones existentes si cambiamos a la API o qué modificaciones técnicas serían necesarias para que la API logre esto? Encontré esta página de ayuda a través de Google, pero no sé si esto refleja la API actual.

Estado:
Se envió una carta a Bryan (disponible para el equipo de desarrollo en la lista de correo de Googlegroups).
Esperando comentarios.

Solo como referencia adicional y en caso de que alguien esté interesado en ver cómo encajaría en el modo de trabajo c: geo:
https://api.groundspeak.com/LiveV6/geocaching.svc/help

@Lineflyer No confío en las API que tienen diferentes tamaños de fuente en su documentación.

Diría que no es una documentación real, sino algo generado automáticamente a partir de los comentarios del código.
Al hacer clic en el enlace, se revelan aún más cosas que me hacen estremecer un poco (Tucson.Geocaching.WCF.API.Geocaching.Types).
Parece que en realidad no están diseñando su API como tal, sino que usan un marco para generar y exponer algo...

Hola,

Esta API quedará obsoleta el 1 de mayo de 2019, pero una nueva API REST está en producción desde hace unos meses, y la URL de devolución de llamada debe ser autorizada por Groundspeak. Entonces, incluso si se conocen las claves, nadie puede usarlas porque GS redirigirá a la URL de devolución de llamada.

(Tengo acceso a esta API).

Me temo que este problema no está actualizado. Mientras tanto, los desarrolladores del equipo central de c:geo tienen la posibilidad de acceder a la última API (entorno de preparación) y la documentación también está disponible.
Si está interesado en ayudar, debemos aclarar qué necesitaría para eso y proporcionarle el acceso adecuado.

Me gustaría ayudarlo, pero soy un desarrollador web (php/go), no un desarrollador de Android.

Para actualizar este problema: Estamos en contacto con Groundspeak desde hace mucho tiempo, evaluando cómo podemos usar la API. Aún quedan algunos problemas abiertos (no técnicos) por resolver, pero ya recibimos las claves de desarrollo para la nueva API. Como siguiente paso, tenemos que diseñar la integración en c:geo (por ejemplo, si es solo un nuevo conector o si son necesarios otros cambios). Para eso y la siguiente fase de implementación, se agradece cualquier ayuda.

Algunos términos de uso de Groundspeak API eran problemáticos en el pasado (claves imposibles o difíciles de obtener para fines de desarrollo para cualquiera que las pidiera, limitaciones diarias drásticas en la cantidad de cachés recuperados y sus calificaciones D/T para miembros básicos, imposible mostrar cachés de sitios web simultáneos como opencaching...), ¿se resolvieron estos problemas o son los problemas restantes no técnicos que mencionas?
No veo que Groundspeak cambie de opinión sobre su modelo de negocio y su (falta de) apertura, viendo sus restricciones API actuales.

Bueno, Groundspeak mostró cierta voluntad de discutir estos temas no técnicos y ya dimos algunas propuestas. Sin embargo, para seguir discutiendo esto, probablemente necesitemos ver el impacto/la diferencia entre el uso de la API y la implementación actual en el flujo de uso.

Preferiría no proporcionar ningún detalle en este foro abierto, sin embargo, seguramente incluiremos en esta discusión a cualquiera que esté dispuesto a trabajar en la implementación de la API, además de involucrar a nuestros usuarios antes de una decisión final.

¿Algo nuevo aquí? Probé la API antes y no es tan malo implementarla. También miré la nueva versión que tienen ahora.
La pregunta es: ¿alguien está liderando este tema?
Siento que podría ser un gran impulso para que c:geo logre esto.
¿Cuál es el retraso técnico?

¿Cuál es el retraso técnico?

Básicamente mano de obra.

Pero todavía hay algunas cuestiones abiertas con respecto a los términos de uso. Por lo tanto, es muy posible que una implementación técnica no se utilice en la forma actual o en absoluto si no hay un acuerdo con Groundspeak.

Creo que deberíamos comenzar con algún tipo de análisis de requisitos abstractos, luego proceder con una lista de áreas afectadas en c:geo y los cambios necesarios.

No hay retención técnica. Sin embargo, debe verificarse en detalle si la Api es capaz de soportar toda la funcionalidad que ahora tenemos.
Desde mi punto de vista personal, hay una falta de recursos y una falta de un acuerdo aceptable con respecto al uso de Api para miembros básicos.
Por cierto: ¿Dónde ve el impulso para c:geo como tal en este tema? Sería un poco 'más barato' en términos de recursos de desarrollo y sería más barato para GroundSpeak servir a los usuarios de c:geo, pero ¿de lo contrario? No veo grandes ventajas en c:geo usando la Api para el 'Joe promedio'. Los usuarios avanzados ciertamente tienen otros flujos de trabajo que involucran GSAK y herramientas móviles que se conectan a esa cadena.

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

pstorch picture pstorch  ·  4Comentarios

SammysHP picture SammysHP  ·  5Comentarios

wolverine007 picture wolverine007  ·  3Comentarios

SammysHP picture SammysHP  ·  6Comentarios

jonas-koeritz picture jonas-koeritz  ·  4Comentarios