Cgeo: API Geocaching.com

Cela devrait bien sûr être coordonné avec #9...

où est la nouvelle api ?? Je pense que s'il existe une API qui prend en charge toutes les fonctionnalités, nous devrions l'utiliser. (mais seulement si groundpeak change l'API immédiatement s'ils font une mise à jour sur geocaching.com)

Api est disponible uniquement pour les applications sélectionnées. Cgeo en était un, cgeo opensource n'est pas

J'espère qu'ils ne changent pas l'API à chaque modification des pages Web...
Sinon, nous pourrions continuer à explorer les pages et mettre à jour notre code à chaque modification apportée par GC.com à leurs pages Web...
J'ai lu que l'API sera désormais disponible à la fois pour les membres premium et de base avec certaines limitations pour les membres de base.
Si cela ne vous dérange pas, je vais contacter Ryan chez Groundspeak et lui demander de la documentation sur l'API.
Florian.

Nous avons doc, nous n'avons pas de clé d'accès API

J'ai lu la notification concernant l'API à venir il y a quelques semaines. Est-ce que quelqu'un a d'autres pointeurs?

:( Je voulais dire qu'ils mettent à jour la bibliothèque après les changements sur gc.com :D

Donc, si cela ne vous dérange pas, je demanderais à Groundspeak une clé d'accès API pour c-geo (et également clarifier avec Groundspeak que c-geo-opensource est fondamentalement le même que c-geo avec juste une clarification sur la licence opensource ).
Pouvez-vous m'envoyer une copie de la documentation ou - si elle se trouve quelque part sur le Web - me donner un lien vers celle-ci ?
Florian.

Sammy a communiqué. Attendons-le

Je les ai contacté il y a quelques semaines. La réponse était une ligne qui m'a dit de leur envoyer une application pour accéder à l'API. Il semble qu'il n'y ait pas de documentation publique, vous avez besoin d'une clé API pour l'application et chaque utilisateur doit obtenir une clé via une procédure OAuth. Et ils l'appellent "API publique"...

Je pense que nous ne devrions pas le coder en dur. Ce sera plus facile avec le connecteur-interface pour que cela ne fasse aucune différence si nous importons depuis spidering, API, OC, gpx, web2cgeo...

Absolument. Je n'ai pas pensé à l'authentification OAuth lorsque j'ai pensé passer successivement à la nouvelle API.

@SammysHP : Alice au pays des merveilles de Groundsheep :

"Quand j'utilise un mot", a déclaré Humpty Dumpty d'un ton plutôt méprisant, "cela signifie exactement ce que je choisis qu'il signifie - ni plus ni moins."
"La question est," dit Alice, "si vous pouvez faire en sorte que les mots signifient tant de choses différentes."
"La question est," dit Humpty Dumpty, "qui doit être maître - - c'est tout."

Hier j'ai reçu un mail de Groundspeak :

Cher Sven,

Merci de votre patience alors que nous avançons avec le programme API Geocaching.com. Vous trouverez ci-joint deux documents à consulter. Veuillez me renvoyer le formulaire d'inscription API dûment rempli et nous vous enverrons une clé de test API.

L'objectif de ce programme d'API public est de permettre à des tiers de confiance de développer des applications et des services à l'aide de l'ensemble de données geocaching.com qui servira principalement aux membres Groundspeak Premium, tout en permettant également de fournir une quantité importante de services aux membres de base. L'API sera fournie sans redevance, afin que les développeurs puissent générer des revenus (ou non) comme ils l'entendent, sans avoir à payer de redevances à Groundspeak pour l'accès aux données.

Nous pensons que cela vous permettra de mieux servir la communauté au sens large, y compris les nouveaux utilisateurs, tout en offrant aux membres de base des opportunités supplémentaires de passer aux services Premium complets. Idéalement, nous aimerions que les membres qui apprécient les expériences d'introduction passent à l'adhésion Premium pour un accès complet aux applications/services. Les détails spécifiques concernant cette structure sont contenus dans l'annexe A de l'accord. Un accord avec les conditions et un formulaire d'inscription API rempli seront requis avant l'accès à la base de données de production et le lancement officiel.

Veuillez noter qu'en tant que développeur de confiance, nous nous attendons à ce que vous n'abusiez pas de l'API, que ce soit en préproduction ou en production. Le grattage du site Web pour les données geocaching.com n'est autorisé dans aucune application ou service pour les membres de base ou premium. Plutôt que d'autoriser le scraping, nous préférerions développer des appels d'API pour répondre aux besoins spécifiques des développeurs. Si vous avez des questions concernant les actions potentielles que vous envisagez d'effectuer avec l'API, veuillez les publier sur les forums de l'API et nous ferons de notre mieux pour clarifier les règles.

Une connexion via Oauth sera requise pour tous les utilisateurs des applications/services activés par l'API. Après avoir reçu votre formulaire d'inscription à l'API dûment rempli, nous vous enverrons une clé de test pour vous permettre d'accéder au serveur intermédiaire. Ensuite, après avoir examiné votre produit et ses fonctionnalités, nous avancerons avec la clé API de production.

Merci encore. Nous sommes très impatients de travailler avec vous.

Meilleures salutations,

Christy

Christy Luther
Responsable du développement commercial
Groundspeak, Inc.
Groundspeak - Le langage du lieu
www.groundspeak.com
www.geocaching.com

Voici le contrat de licence de l'API : http://www.file-upload.net/download-3675937/Groundspeak-API-License-Agreement-17-08-2011.pdf.html

Le problème est que la clé doit être publique car chaque développeur compile sa propre version (pour tester et utiliser). Et d'après ce que j'ai entendu, c'est un problème pour Groundspeak.
Donc ma suggestion : attendez que l'interface du connecteur soit réalisée, puis développez l'utilisation de l'API en tant qu'application distincte.

Salut, j'ai brièvement parcouru le contrat de licence. Bien que je ne vois pas de demande explicite de confidentialité par rapport à la clé API qui pourrait peut-être être dérivée de 4.17 ou 4.18.
Ce qui tue le concept d'un connecteur externe est probablement 4.16 (travail dérivé) et 5.3 (utilisateurs finaux - pas d'autres applications).
L'intégrer dans c:geo violerait 4.14.
Les limites de base des membres sont une blague.
Je vote pour l'ignorer jusqu'à ce qu'ils proposent un modèle de licence raisonnable.

Je pense qu'il n'y a pas de problème à coller un e-mail que quelqu'un a reçu de Bryan :

Salut _________,

Nous sommes disposés à fournir un accès API à CGeo Opensource. Cependant, étant donné que la clé de licence ne doit être utilisée que pour l'application individuelle, nous craignons qu'elle ne soit partagée publiquement. S'il est partagé publiquement, il pourrait être utilisé par d'autres applications et cela obligerait Groundspeak à annuler la clé spécifique. Cela casserait bien sûr l'application car elle ne pourrait pas accéder aux données.

Alors, pouvez-vous m'aider à comprendre comment vous envisagez de limiter l'accès à la clé d'authentification ? Il ne peut en aucun cas être rendu public. Puisqu'il y a un certain nombre de développeurs travaillant sur le projet Opensource, nous savons qu'il suffit d'un seul développeur pour fournir le code en externe et nous aurons alors tous un problème. Veuillez fournir toutes les informations que vous pouvez et nous serions heureux de travailler directement avec vous, ou le représentant principal du projet, pour que cela fonctionne.

J'ai inclus Christy Luther dans cet e-mail car elle gère le processus de développement pour les développeurs tiers.

Merci!

Sincèrement,

Bryan

Ils sont donc prêts à nous aider, mais aussi mon avis est d'attendre (pour une meilleure intégration, une licence moins stricte, peut-être une API qui n'a pas besoin de clé, mais seulement la clé OAuth).

ce qui m'éblouit : Google est capable de gérer de tels modèles de développement pour leurs api de cartes. Mais les moutons de terre ne peuvent pas ? Bizarre.

Il y a deux choses avec Google :

• L'API Google vérifie le certificat, avec lequel l'application est signée. La clé de Groundspeak devrait fonctionner avec toutes les plates-formes et tous les langages de programmation.
• La clé API Google est gratuite, donc chaque développeur peut en obtenir une.

Je sais. C'est le processus de l'api groundsheep qui cause des problèmes ici alors que différentes cultures se heurtent : le "sortez de ma cour" rigide et semblable à une pomme de St Jeremy et le bazar ouvert, où google est fort. Il ne pourrait plus y avoir de contraste. En ce qui concerne la partie dépendante d'Android : si je me souviens bien, vous pouvez également utiliser Google Maps à partir d'applications Web javascript, de sorte qu'elles semblent avoir mis en place une méthode indépendante de la plate-forme. C'est l'état d'esprit différent entre Google et Groundsheep qui cause les hoquets, Google n'est pas méchant, mais qu'est-ce que Groundsheep ?

AFAIK la clé pour JavaScript vérifie le domaine.

Jetez un autre regard, cette fois sur l'infrastructure OSM : ils doivent exploiter un environnement ouvert, tout en projetant leur base de données contre les abus. Ils ne vérifient pas les applications pour modifier les données OSM : comment cela devrait-il fonctionner ? À chaque nouvelle version, patch, etc., St Jeremy veut-il vérifier à nouveau chaque application ? Contrôler la névrose, quelqu'un ? Ainsi, OSM vérifie les utilisateurs. Ne semble pas être un problème. Peut-être qu'il me manque quelque chose, mais alors pourquoi le modèle OSM ne fonctionnerait-il pas pour les données de géocaching ?

C'est ce que j'ai pensé quand j'ai entendu parler de la nouvelle API publique.

Le problème avec la clé API pourrait peut-être être résolu si chaque développeur obtient sa propre clé - mais en regardant les limitations pour les membres de base, je vote contre l'utilisation de l'API.

BFKC est en contact avec Groundspeak, alors attendons. De plus, la seule possibilité d'implémenter l'API est un connecteur comme celui de GeOrg : http://android.ranitos.de/files/connector-sample.zip J'aime la manière dont est utilisée la communication entre l'application et le connecteur.

En attendant, vous pouvez me MP si vous voulez un lien vers la documentation de l'API.

En fermant ceci pour le moment, nous garderons cela à l'esprit et en reparlerons lorsque l'interface du connecteur sera implémentée. Voir #10

L'utilisateur final pourrait être responsable d'entrer une clé d'utilisateur valide dans c:geo. Les développeurs peuvent développer chacun avec leur propre clé d'utilisateur.

Non, OAuth nécessite une clé secrète pour l'application.

Oui une clé secrète pour générer une clé utilisateur. Ensuite, la clé utilisateur est utilisée pour communiquer avec le serveur API. Comment / où l'utilisateur y parvient dépend d'eux.

Vous dites, nous devrions utiliser le compte d'une autre application pour nos besoins ? !

Quel est le problème si un seul développeur obtient la clé ?
Il doit y avoir quelqu'un qui est responsable de la publication des versions "officielles" dans la boutique Google.
Ainsi, ce développeur ajouterait la clé API dans un fichier de configuration qui serait intégré à l'apk.
Si d'autres développeurs souhaitent travailler sur la partie API du code, ils peuvent demander eux-mêmes l'accès à l'API !
Les personnes qui souhaitent utiliser des versions personnalisées de c:geo auraient évidemment besoin de leur propre clé API, mais je pense que la majorité des utilisateurs ne souhaitent pas utiliser de versions personnalisées. Dans tous les cas, ce serait mieux que pas de support API du tout !

La question de la clé n'est qu'un problème mineur. Le principal problème est que, selon les conditions de licence fondamentales, vous ne devez pas mettre de caches dans votre application par d'autres moyens que l'API.
Cela signifierait que nous devions construire toutes les fonctionnalités autour de l'API, faisant de c:geo une application uniquement Premium.

Eh bien, une courte mise à jour concernant ce problème.

• Lien vers le contrat de licence API : http://www.geocaching.com/live/api_license_agreement.aspx
• Il existe un nouveau connecteur pour GeOrg fournissant un accès à gc.com via l'API : https://play.google.com/store/apps/details?id=georg.connector.gcapi
  Je suis en contact avec le développeur et ce n'est pas aussi simple qu'il y paraît. Je ne peux pas en dire grand-chose en public.
• Il y avait un plugin pour Locus, geocaching4locus : http://geocaching4locus.eu/
  Il a également fourni un accès aux membres de base et en plus aux membres premium (via l'API). Mais maintenant, il était bloqué par Groundspeak :

Chers utilisateurs,

Comme certains d'entre vous le savent, nous avons essayé de fournir un service aux membres de base et premium avec la même limitation. Ainsi, nous avons violé le contrat de licence de l'API Geocaching pour les membres de base. Malheureusement, Groundspeak, Inc. (la société qui s'occupe du site Geocaching.com) a détecté nos actions et nous avons été contraints de suspendre temporairement la distribution de notre application sur Google Play et d'autres magasins d'applications. Certains d'entre vous ont probablement rencontré des problèmes de connexion au cours des derniers jours, ce qui peut être lié à cela.

Après avoir longuement réfléchi nous avons décidé de légaliser notre application, mais malheureusement cela touche les membres de base. Parce que les membres de base sont limités à télécharger trois géocaches complètes par jour par cet accord de licence. C'est la raison pour laquelle nous avons fait ce que nous faisions avant. Pour les membres premium, la limite sera la même qu'avant, 6 000 Géocaches par jour.

L'adaptation à de nouvelles règles prendra plusieurs jours en raison de l'ajout de boîtes de dialogue de confirmation pour les membres de base requis par ce contrat de licence. J'espère que nous publierons une nouvelle version dès que possible même au prix de traductions incomplètes.

L'équipe de développeurs Geocaching4Locus

En supposant que c:geo puisse obtenir l'accès à l'API de Groundspeak :

1. Quels points de l' accord de licence d'API existant devraient être discutés et/ou modifiés pour répondre à nos exigences ?
2. Pouvons-nous conserver toutes les fonctions existantes si nous changeons d'API ou quelles modifications techniques seraient nécessaires pour que l'API y parvienne ? J'ai trouvé cette page d'aide via Google, mais je ne sais pas si cela reflète l'API actuelle.

Voir aussi le journal IRC du 18.05.2015

Statut:
La lettre à Bryan a été envoyée (disponible pour l'équipe de développement sur la liste de diffusion Googlegroups).
En attente de commentaires.

Juste pour plus de référence et au cas où quelqu'un voudrait voir comment cela correspondrait au mode de travail c: geo :
https://api.groundspeak.com/LiveV6/geocaching.svc/help

@Lineflyer Je ne fais pas confiance aux API qui ont des tailles de police différentes dans leur documentation.

Ce n'est pas une vraie documentation, je dirais, mais quelque chose généré automatiquement à partir de commentaires de code.
Cliquer sur le lien révèle encore plus de choses qui me font légèrement frissonner (Tucson.Geocaching.WCF.API.Geocaching.Types).
On dirait qu'ils ne conçoivent pas vraiment leur API en tant que telle, mais utilisent un framework pour générer et exposer quelque chose...

Bonjour,

Cette API sera obsolète le 1er mai 2019 mais une nouvelle API REST est en production depuis quelques mois maintenant, et l'URL de rappel doit être autorisée par Groundspeak. Ainsi, même si les clés sont connues, personne ne peut l'utiliser car GS redirigera vers l'URL de rappel.

(J'ai accès à cette API).

• Documentation pour les développeurs - https://api.groundspeak.com/documentation
• Documentation Swagger - https://api.groundspeak.com/api-docs/index

J'ai peur, ce problème n'est pas à jour. Pendant ce temps, les développeurs de l'équipe c:geo ont la possibilité d'accéder à la dernière API (environnement de développement) et la documentation est également disponible.
Si vous êtes intéressé à aider, nous devons clarifier ce dont vous auriez besoin pour cela et fournir un accès approprié

J'aimerais vous aider mais je suis développeur web (php/go), pas Android Dev..

Pour mettre à jour ce problème : nous sommes en contact avec Groundspeak depuis longtemps, évaluant comment nous pouvons utiliser l'API. Il reste encore quelques problèmes ouverts (non techniques) à résoudre, mais nous avons déjà reçu des clés de développement pour la nouvelle API. Dans l'étape suivante, nous devons concevoir l'intégration dans c:geo (par exemple s'il s'agit simplement d'un nouveau connecteur ou si d'autres modifications sont nécessaires). Pour cette phase de mise en œuvre et la suivante, toute aide est appréciée.

Certaines conditions d'utilisation de l'API Groundspeak étaient problématiques dans le passé (impossible ou difficile d'obtenir des clés à des fins de développement pour quiconque le demandait, limitations quotidiennes drastiques du nombre de caches récupérés et de leurs notes D/T pour les membres de base, impossible d'afficher les caches à partir de sites Web concurrents comme opencaching…), ces problèmes ont-ils été résolus ou s'agit-il de problèmes restants non techniques que vous mentionnez ?
Je ne vois pas Groundspeak changer d'avis sur son business model et son (manque d') ouverture, vu ses restrictions API actuelles.

Eh bien, Groundspeak a montré une certaine volonté de discuter de ces questions non techniques et nous avons déjà fait quelques propositions. Cependant, pour en discuter plus en détail, nous devons probablement voir l'impact/la différence entre l'utilisation de l'API et l'implémentation actuelle dans le flux d'utilisation.

Je préférerais ne pas fournir de détails dans ce forum ouvert, mais nous prendrons à coup sûr toute personne désireuse de travailler sur la mise en œuvre de l'API dans cette discussion ainsi que d'impliquer nos utilisateurs avant une décision finale.

Quelque chose de nouveau ici? J'ai essayé l'API avant et ce n'est pas trop mal à mettre en œuvre. J'ai également regardé la nouvelle version qu'ils ont maintenant.
La question est : quelqu'un dirige-t-il ce sujet ?
J'ai l'impression que cela pourrait être un grand coup de pouce pour c:geo pour y parvenir.
Quel est le retard technique ?

Quel est le retard technique ?

Essentiellement la main-d'oeuvre.

Mais il y a encore quelques questions ouvertes concernant les conditions d'utilisation. Il est donc fort possible qu'une implémentation technique ne soit pas utilisée sous sa forme actuelle ou pas du tout s'il n'y a pas d'accord avec Groundspeak.

Je pense que nous devrions commencer par une sorte d'analyse abstraite des exigences, puis procéder à une liste des zones affectées dans c:geo et des changements nécessaires.

Il n'y a pas de blocage technique. La capacité de l'API à supporter toutes les fonctionnalités dont nous disposons maintenant doit cependant être vérifiée en détail.
De mon côté, il y a un manque de ressources et un manque d'accord acceptable concernant l'utilisation de l'API pour les membres de base.
BTW : Où voyez-vous le coup de pouce pour c:geo en tant que tel dans ce sujet ? Ce serait un peu moins cher en termes de ressources de développement et il serait moins cher pour Groundspeak de servir les utilisateurs de c:geo, mais sinon ? Je ne vois pas de gros avantages à c:geo en utilisant l'API pour le "Joe moyen". Les utilisateurs expérimentés ont certainement d'autres flux de travail impliquant GSAK et des outils mobiles qui se connectent à cette chaîne.