Cgeo: Geocaching.com-API

Das müsste natürlich mit #9 abgestimmt werden...

Wo ist die neue API?? Ich denke, wenn es eine API gibt, die alle Funktionen unterstützt, sollten wir diese verwenden. (aber nur wenn groundpeak die API sofort ändert, wenn sie ein Update auf geocaching.com machen)

API ist nur für ausgewählte Apps verfügbar. Cgeo war einer, cgeo Opensource ist es nicht

Ich würde hoffen, dass sie die API nicht bei jeder Änderung an den Webseiten ändern ...
Andernfalls könnten wir die Seiten weiterhin crawlen und unseren Code mit jeder Änderung aktualisieren, die GC.com an ihren Webseiten implementiert ...
Ich habe gelesen, dass die API jetzt sowohl für Premium- als auch für Basismitglieder verfügbar sein wird, mit einigen Einschränkungen für Basismitglieder.
Wenn es Ihnen nichts ausmacht, werde ich mich mit Ryan von Groundspeak in Verbindung setzen und ihn um eine API-Dokumentation bitten.
Florian.

Wir haben doc, wir haben keinen API-Zugriffsschlüssel

Ich habe vor einigen Wochen die Benachrichtigung über die kommende API gelesen. Hat jemand noch ein paar Hinweise?

:( Ich meinte, sie aktualisieren die Bibliothek nach Änderungen auf gc.com :D

Wenn es Ihnen also nichts ausmacht, würde ich Groundspeak nach einem API-Zugriffsschlüssel für c-geo fragen (und auch mit Groundspeak klarstellen, dass c-geo-opensource im Grunde dasselbe ist wie c-geo, nur mit einer Klarstellung zur Opensource-Lizenzierung ).
Können Sie mir eine Kopie der Dokumentation schicken oder - falls es irgendwo im Internet steht - einen Link dazu geben?
Florian.

Sammy hat kommuniziert. Warten wir auf ihn

Ich habe sie vor ein paar Wochen kontaktiert. Die Antwort war eine Zeile, in der ich aufgefordert wurde, ihnen eine Anwendung für den Zugriff auf die API zu senden. Es scheint, dass es keine öffentliche Dokumentation gibt, man braucht einen API-Schlüssel für die App und jeder Benutzer muss einen Schlüssel über ein OAuth-Verfahren bekommen. Und sie nennen es "öffentliche API" ...

Ich denke, wir sollten es nicht fest codieren. Einfacher wird es mit der Connector-Schnittstelle, so dass es keinen Unterschied macht, ob wir von Spidering, API, OC, gpx, web2cgeo importieren ...

Absolut. An die OAuth-Authentifizierung habe ich nicht gedacht, als ich daran dachte, sukzessive auf die neue API umzustellen.

@SammysHP : Alice im Groundsheep Wonderland:

„Wenn ich ein Wort benutze“, sagte Humpty Dumpty in einem ziemlich verächtlichen Ton, „bedeutet es genau das, was ich es auswähle – weder mehr noch weniger.“
„Die Frage ist,“ sagte Alice, „ob man Wörter dazu bringen kann, so viele verschiedene Dinge zu bedeuten.“
„Die Frage ist,“ sagte Humpty Dumpty, „wer Herr sein soll – das ist alles.“

Gestern bekam ich eine Mail von Groundspeak:

Lieber Sven,

Vielen Dank für Ihre Geduld, während wir mit dem API-Programm von Geocaching.com vorankommen. Im Anhang sind zwei Dokumente, die Sie sich ansehen können. Bitte senden Sie mir das ausgefüllte API-Registrierungsformular zurück und wir senden Ihnen einen API-Testschlüssel zu.

Das Ziel dieses öffentlichen API-Programms ist es, vertrauenswürdigen Dritten die Entwicklung von Anwendungen und Diensten unter Verwendung des geocaching.com-Datensatzes zu ermöglichen, der hauptsächlich Groundspeak-Premium-Mitgliedern dient, während gleichzeitig eine beträchtliche Anzahl von Diensten für Basis-Mitglieder bereitgestellt wird. Die API wird gebührenfrei bereitgestellt, sodass Entwickler nach eigenem Ermessen Einnahmen erzielen können (oder auch nicht), ohne Lizenzgebühren an Groundspeak für den Datenzugriff zahlen zu müssen.

Wir glauben, dass dies Ihnen die Möglichkeit bietet, die breitere Community, einschließlich neuer Benutzer, am besten zu bedienen, und gleichzeitig zusätzliche Möglichkeiten für Basic-Mitglieder bietet, ein Upgrade auf vollständige Premium-Dienste durchzuführen. Im Idealfall möchten wir, dass Mitglieder, die die Einführungserlebnisse genießen, auf die Premium-Mitgliedschaft upgraden, um vollen Zugriff auf Anwendungen/Dienste zu erhalten. Spezifische Einzelheiten zu dieser Struktur sind in Anhang A der Vereinbarung enthalten. Die Zustimmung zu den Bedingungen und ein ausgefülltes API-Registrierungsformular sind vor dem Zugriff auf die Produktionsdatenbank und dem formellen Start erforderlich.

Bitte beachten Sie, dass wir als vertrauenswürdiger Entwickler erwarten, dass Sie die API weder in der Bereitstellung noch in der Produktion missbrauchen. Das Scrapen der Website für geocaching.com-Daten ist in keiner Anwendung oder keinem Dienst für Basis- oder Premium-Mitglieder gestattet. Anstatt das Scraping zuzulassen, würden wir es vorziehen, API-Aufrufe zu entwickeln, um den spezifischen Anforderungen der Entwickler gerecht zu werden. Wenn Sie Fragen zu möglichen Aktionen haben, die Sie mit der API durchführen möchten, posten Sie diese bitte in den API-Foren und wir werden unser Bestes tun, um die Regeln zu klären.

Für alle Benutzer der API-fähigen Anwendungen/Dienste ist eine Anmeldung über Oauth erforderlich. Nachdem Sie Ihr ausgefülltes API-Registrierungsformular erhalten haben, senden wir Ihnen einen Testschlüssel für den Zugriff auf den Staging-Server. Nachdem wir Ihr Produkt und Ihre Funktionalität überprüft haben, werden wir mit dem Produktions-API-Schlüssel fortfahren.

Danke nochmal. Wir freuen uns sehr auf die Zusammenarbeit mit Ihnen.

Mit freundlichen Grüßen,

Christy

Christy Luther
Geschäftsentwicklungsmanager
Groundspeak, Inc.
Groundspeak - Die Sprache des Ortes
www.groundspeak.com
www.geocaching.com

Hier ist die API-Lizenzvereinbarung: http://www.file-upload.net/download-3675937/Groundspeak-API-License-Agreement-17-08-2011.pdf.html

Das Problem ist, dass der Schlüssel öffentlich sein muss, da jeder Entwickler seinen eigenen Build kompiliert (zum Testen und Verwenden). Und nach dem, was ich gehört habe, ist das ein Problem für Groundspeak.
Daher mein Vorschlag: Warten Sie, bis die Connector-Schnittstelle realisiert ist, und entwickeln Sie dann die Verwendung der API als separate App.

Hallo, ich habe kurz die Lizenzvereinbarung überflogen. Wobei ich keine ausdrückliche Bitte um Vertraulichkeit in Bezug auf den API-Schlüssel sehe, der vielleicht aus 4.17 oder 4.18 abgeleitet werden kann.
Was das Konzept eines externen Konnektors zunichte macht, ist wahrscheinlich 4.16 (abgeleitete Arbeit) und 5.3 (Endbenutzer - keine anderen Apps).
Die Integration in c:geo würde gegen 4.14 verstoßen.
Die grundlegenden Mitgliederlimits sind ein Witz.
Ich stimme dafür, es einfach zu ignorieren, bis sie ein vernünftiges Lizenzmodell finden.

Ich denke, es ist in Ordnung, eine Mail einzufügen, die jemand von Bryan bekommen hat:

Hallo _________,

Wir sind bereit, API-Zugriff auf CGeo Opensource bereitzustellen. Da der Lizenzschlüssel jedoch nur für die jeweilige Anwendung verwendet werden darf, befürchten wir, dass er öffentlich geteilt werden könnte. Wenn es öffentlich geteilt wird, könnte es von anderen Anwendungen verwendet werden und das würde dazu führen, dass Groundspeak gezwungen wäre, den spezifischen Schlüssel zu löschen. Dies würde natürlich die Anwendung zerstören, da sie nicht auf Daten zugreifen könnte.

Können Sie mir bitte helfen, zu verstehen, wie Sie den Zugriff auf den Authentifizierungsschlüssel einschränken möchten? Es kann unter keinen Umständen öffentlich veröffentlicht werden. Da mehrere Entwickler an dem Opensource-Projekt arbeiten, wissen wir, dass es nur einen Entwickler braucht, der den Code extern bereitstellt, und dann haben wir alle ein Problem. Bitte geben Sie alle Informationen an, die Ihnen zur Verfügung stehen, und wir würden uns freuen, direkt mit Ihnen oder dem Hauptvertreter des Projekts zusammenzuarbeiten, damit dies funktioniert.

Ich habe Christy Luther in diese E-Mail aufgenommen, da sie den Entwicklungsprozess für Drittentwickler verwaltet.

Danke schön!

Aufrichtig,

Bryan

Sie sind also bereit, uns zu helfen, aber meiner Meinung nach ist auch zu warten (für eine bessere Integration, weniger strenge Lizenz, vielleicht eine API, die keinen Schlüssel benötigt, sondern nur den OAuth-Schlüssel).

Was mich verblüfft: Google ist in der Lage, solche Entwicklungsmodelle für ihre Maps-API zu verwalten. Aber Bodenschafe können das nicht? Bizarr.

Bei Google gibt es zwei Dinge:

• Die Google API prüft das Zertifikat, mit dem die App signiert wird. Der Key von Groundspeak sollte mit jeder Plattform und Programmiersprache funktionieren.
• Der Google-API-Schlüssel ist kostenlos, sodass jeder Entwickler einen bekommen kann.

Ich weiss. Es ist der Groundsheep-API-Prozess, der hier Probleme verursacht, wenn verschiedene Kulturen aufeinanderprallen: das starre, apfelartige „Runter von meinem Platz“ von St. Jeremy und das offene Basar-ähnliche, wo Google stark ist. Es könnte keinen Kontrast mehr haben. Was den Android-abhängigen Teil betrifft: Wenn ich mich richtig erinnere, können Sie Google Maps auch von Javascript-Web-Apps verwenden, sodass sie anscheinend eine plattformunabhängige Methode haben. Es ist die unterschiedliche Denkweise zwischen Google und Groundsheep, die den Schluckauf verursacht, Google ist nicht böse, aber was ist Groundsheep?

AFAIK der Schlüssel für JavaScript überprüft die Domäne.

Werfen Sie einen weiteren Blick, diesmal auf die OSM-Infrastruktur: Sie müssen eine offene Umgebung betreiben, aber ihre Datenbank vor Missbrauch schützen. Sie prüfen die Apps nicht auf die Bearbeitung von OSM-Daten: Wie soll das überhaupt funktionieren? Mit jedem neuen Release, Patch, etc. ... will St. Jeremy jede App erneut überprüfen? Kontrollneurose, jemand? OSM überprüft also die Benutzer. Scheint kein Problem zu sein. Vielleicht übersehe ich etwas, aber warum sollte das OSM-Modell dann nicht für Geocaching-Daten funktionieren?

Das waren meine Gedanken, als ich von der neuen, öffentlichen API hörte.

Das Problem mit dem API-Schlüssel könnte vielleicht gelöst werden, wenn jeder Entwickler seinen eigenen Schlüssel bekommt - aber mit Blick auf die Einschränkungen für Basic-Mitglieder stimme ich gegen die Verwendung der API.

BFKC steht in Kontakt mit Groundspeak, also warten wir ab. Auch die einzige Möglichkeit, die API zu implementieren, ist ein Konnektor wie der von GeOrg: http://android.ranitos.de/files/connector-sample.zip Ich mag die Art und Weise, die für die Kommunikation zwischen der App und dem Konnektor verwendet wird.

In der Zwischenzeit können Sie mir eine PN senden, wenn Sie einen Link zur API-Dokumentation wünschen.

Wir schließen dies für den Moment ab, wir werden dies im Hinterkopf behalten und erneut darüber sprechen, wenn die Connector-Schnittstelle implementiert ist. Siehe Nr. 10

Der Endbenutzer könnte dafür verantwortlich sein, einen gültigen Benutzerschlüssel in c:geo einzugeben. Entwickler können jeweils mit ihrem eigenen Benutzerschlüssel entwickeln.

Nein, OAuth erfordert einen geheimen Schlüssel für die App.

Ja, ein geheimer Schlüssel, um einen Benutzerschlüssel zu generieren. Dann wird der Benutzerschlüssel verwendet, um mit dem API-Server zu kommunizieren. Wie / wo der Benutzer an den Schlüssel kommt, ist ihm überlassen.

Du sagst, wir sollen den Account einer anderen App für unsere Zwecke nutzen?!

Was ist das Problem, wenn nur ein Entwickler den Schlüssel bekommt?
Es muss jemanden geben, der für die Veröffentlichung der "offiziellen" Veröffentlichungen im Google Store verantwortlich ist.
Dieser Entwickler würde also den API-Schlüssel in eine Konfigurationsdatei einfügen, die in die apk gepackt wird.
Wenn andere Entwickler am API-Teil des Codes arbeiten möchten, können sie selbst einen API-Zugriff beantragen!
Leute, die benutzerdefinierte Versionen von c:geo verwenden möchten, benötigen natürlich ihren eigenen API-Schlüssel, aber ich denke, die Mehrheit der Benutzer möchte keine benutzerdefinierten Versionen verwenden. Das wäre in jedem Fall besser als gar keine API-Unterstützung!

Die Frage nach dem Schlüssel ist nur ein kleines Problem. Das Hauptproblem ist, dass Sie gemäß den Groundspeak-Lizenzbedingungen Caches nicht auf andere Weise als über die API in Ihre App bekommen dürfen.
Das würde bedeuten, dass wir die gesamte Funktionalität um die API herum aufbauen müssten, wodurch c:geo effektiv zu einer Nur-Premium-App wird.

Nun, ein kurzes Update zu diesem Problem.

• Link zur API-Lizenzvereinbarung: http://www.geocaching.com/live/api_license_agreement.aspx
• Es gibt einen neuen Connector für GeOrg, der gc.com-Zugriff über die API bereitstellt: https://play.google.com/store/apps/details?id=georg.connector.gcapi
  Ich bin mit dem Entwickler in Kontakt und es ist nicht so einfach, wie es aussieht. Öffentlich kann ich dazu nicht viel sagen.
• Es gab ein Plugin für Locus, geocaching4locus: http://geocaching4locus.eu/
  Es ermöglichte den Zugriff auch für Basismitglieder und zusätzlich für Premiummitglieder (über die API). Aber jetzt wurde es von Groundspeak blockiert:

Liebe Benutzer,

Wie einige von Ihnen wissen, haben wir versucht, den Service für Basis- und Premium-Mitglieder mit denselben Einschränkungen anzubieten. Somit haben wir gegen die Geocaching-API-Lizenzvereinbarung für Basismitglieder verstoßen. Leider hat Groundspeak, Inc. (das Unternehmen, das sich um die Website Geocaching.com kümmert) unsere Handlungen entdeckt und wir waren gezwungen, den Vertrieb unserer Anwendung bei Google Play und anderen App-Stores vorübergehend auszusetzen. Einige von Ihnen hatten in den letzten Tagen wahrscheinlich Probleme mit der Anmeldung, die möglicherweise damit zusammenhängen.

Nach langem Überlegen haben wir uns entschieden, unseren Antrag zu legalisieren, aber leider betrifft es die Basismitglieder. Denn die Basis-Mitglieder sind durch diese Lizenzvereinbarung darauf beschränkt, drei vollständige Geocaches pro Tag herunterzuladen. Das war der Grund, warum wir das gemacht haben, was wir vorher gemacht haben. Für Premium-Mitglieder gilt das gleiche Limit wie zuvor, 6.000 Geocaches pro Tag.

Die Anpassung an neue Regeln wird mehrere Tage dauern, da Bestätigungsdialoge für die Basismitglieder hinzugefügt werden, die von dieser Lizenzvereinbarung verlangt werden. Ich hoffe, dass wir so schnell wie möglich eine neue Version veröffentlichen werden, selbst auf Kosten unvollständiger Übersetzungen.

Geocaching4Locus-Entwicklerteam

Angenommen, c:geo könnte API-Zugriff von Groundspeak erhalten:

1. Welche Punkte der bestehenden API-Lizenzvereinbarung müssten diskutiert und/oder geändert werden, um unseren Anforderungen zu entsprechen?
2. Können wir alle bestehenden Funktionen beibehalten, wenn wir auf die API umstellen oder welche technischen Anpassungen wären dafür nötig, damit die API dies erreicht? Ich habe diese Hilfeseite über Google gefunden, weiß aber nicht, ob dies die aktuelle API widerspiegelt.

Siehe auch IRC-Log vom 18.05.2015

Status:
Brief an Bryan wurde gesendet (verfügbar für das Entwicklungsteam auf der Googlegroups-Mailingliste).
Warte auf Feedback.

Nur als weitere Referenz und falls jemand nachsehen möchte, wie das in den c:geo-Arbeitsmodus passen würde:
https://api.groundspeak.com/LiveV6/geocaching.svc/help

@Lineflyer Ich vertraue APIs nicht, die in ihrer Dokumentation unterschiedliche Schriftgrößen haben.

Es ist keine echte Dokumentation, würde ich sagen, sondern etwas, das automatisch aus Codekommentaren generiert wurde.
Ein Klick auf den Link zeigt noch mehr Dinge, die mich leicht erschaudern lassen (Tucson.Geocaching.WCF.API.Geocaching.Types).
Das sieht so aus, als würden sie ihre API nicht wirklich als solche entwerfen, sondern ein Framework verwenden, um etwas zu generieren und bereitzustellen ...

Hallo,

Diese API wird am 1. Mai 2019 veraltet sein, aber eine neue REST-API ist seit einigen Monaten in Produktion, und die Callback-URL muss von Groundspeak autorisiert werden. Selbst wenn die Schlüssel bekannt sind, kann sie niemand verwenden, da GS auf die Callback-URL umleitet.

(Ich habe den Zugriff auf diese API).

• Entwicklerdokumentation – https://api.groundspeak.com/documentation
• Swagger-Dokumentation – https://api.groundspeak.com/api-docs/index

Ich fürchte, dieses Thema ist nicht aktuell. Inzwischen haben die Entwickler des c:geo-Kernteams die Möglichkeit, auf die neueste API (Staging-Umgebung) zuzugreifen, und die Dokumentation ist ebenfalls verfügbar.
Wenn Sie daran interessiert sind, zu helfen, müssen wir klären, was Sie dafür benötigen, und einen entsprechenden Zugang bereitstellen

Ich würde Ihnen gerne helfen, aber ich bin Webentwickler (php/go), kein Android-Entwickler.

Um dieses Problem zu aktualisieren: Wir sind seit langem in Kontakt mit Groundspeak und prüfen, wie wir die API verwenden können. Es gibt noch einige offene (nicht technische) Probleme zu lösen, aber wir haben bereits Entwicklungsschlüssel für die neue API erhalten. Als nächsten Schritt müssen wir die Integration in c:geo gestalten (z. B. wenn es nur ein neuer Connector ist oder andere Änderungen notwendig sind). Für diese und die folgende Implementierungsphase ist jede Hilfe willkommen.

Einige Nutzungsbedingungen der Groundspeak-API waren in der Vergangenheit problematisch (unmöglich oder schwierig, Schlüssel für Entwicklungszwecke zu erhalten, wenn jemand danach fragt, drastische tägliche Beschränkungen in der Anzahl der abgerufenen Caches und ihrer D/T-Bewertungen für Basismitglieder, unmöglich, Caches anzuzeigen von gleichzeitigen Websites wie Opencaching…), wurden diese Probleme behoben oder sind es diese nicht technischen verbleibenden Probleme, die Sie erwähnen?
Ich sehe nicht, dass Groundspeak seine Meinung über sein Geschäftsmodell und seine (mangelnde) Offenheit ändert, wenn man seine aktuellen API- Einschränkungen sieht.

Nun, Groundspeak zeigte eine gewisse Bereitschaft, diese nicht-technischen Probleme zu diskutieren, und wir haben bereits einige Vorschläge gemacht. Um dies jedoch weiter zu diskutieren, müssen wir wahrscheinlich die Auswirkungen/Unterschiede zwischen der API-Nutzung und der aktuellen Implementierung im Nutzungsfluss sehen.

Ich möchte in diesem offenen Forum lieber keine Details preisgeben, aber wir werden sicherlich jeden, der bereit ist, an der API-Implementierung zu arbeiten, in diese Diskussion einbeziehen und unsere Benutzer vor einer endgültigen Entscheidung einbeziehen.

Irgendwas neues hier? Ich habe mich vorher mit der API beschäftigt und es ist nicht schlecht zu implementieren. Habe mir auch die neue Version angeschaut, die sie jetzt haben.
Die Frage ist: Leitet jemand dieses Thema?
Ich habe das Gefühl, dass es für c:geo ein großer Schub sein könnte, dies zu erledigen.
Was ist die technische Verzögerung?

Was ist die technische Verzögerung?

Grundsätzlich Personal.

Es gibt jedoch noch einige offene Fragen zu den Nutzungsbedingungen. So ist es durchaus möglich, dass eine technische Umsetzung in der jetzigen Form nicht oder gar nicht zum Einsatz kommt, wenn es keine Einigung mit Groundspeak gibt.

Ich denke, wir sollten mit einer Art abstrakter Anforderungsanalyse beginnen und dann mit einer Liste der betroffenen Bereiche in c:geo und notwendigen Änderungen fortfahren.

Es gibt keine technischen Verzögerungen. Ob die Api in der Lage ist, alle Funktionalitäten zu tragen, die wir jetzt haben, muss jedoch im Detail geprüft werden.
Aus meiner persönlichen Sicht fehlt es an Ressourcen und an einer akzeptablen Vereinbarung bezüglich der Api-Nutzung für Basismitglieder.
Übrigens: Wo siehst du in diesem Thema den Schub für c:geo als solches? Es wäre ein bisschen billiger in Bezug auf die Entwicklungsressourcen und es wäre billiger für Groundspeak, die c:geo-Benutzer zu bedienen, aber sonst? Ich sehe keine großen Vorteile darin, dass c:geo die Api für den 'durchschnittlichen Joe' verwendet. Die Power-User haben sicherlich andere Workflows mit GSAK und mobilen Tools, die sich in diese Kette einklinken.