Cgeo: Geocaching.com API

这当然必须与＃9协调......

新的api在哪里？？ 我认为如果有一个 API 支持我们应该使用的所有功能。 （但前提是 groundspeak 在 geocaching.com 上进行更新后立即更改 API）

Api 仅适用于选定的应用程序。 Cgeo 是其中之一，cgeo 开源不是

我希望他们不会随着网页的每次更改而更改 API ...
否则，我们可以继续爬取页面并使用 GC.com 对其网页实施的每次更改来更新我们的代码......
我读到 API 现在对高级会员和基本会员都可用，但对基本会员有一些限制。
如果您不介意，我将与 Groundspeak 的 Ryan 取得联系，并向他索要 API 文档。
弗洛里安。

我们有文档，我们没有 api 访问密钥

几周前，我阅读了有关即将推出的 Api 的通知。 有人有更多的指针吗？

:( 我的意思是他们在 gc.com 上进行更改后更新库 :D

因此，如果您不介意，我会向 Groundspeak 询问 c-geo 的 api 访问密钥（并与 Groundspeak 澄清 c-geo-opensource 与 c-geo 基本相同，只是澄清了开源许可）。
你能给我一份文档的副本吗？或者——如果它在网络上的某个地方——给我一个链接吗？
弗洛里安。

萨米确实沟通过。 让我们等他

几周前我联系了他们。 响应是一行告诉我向他们发送访问 API 的应用程序。 似乎没有公共文档，您需要一个应用程序端的 API 密钥，每个用户都必须通过 OAuth 程序获得一个密钥。 他们称之为“公共 API”......

我认为我们不应该对其进行硬编码。 使用连接器接口会更容易，因此如果我们从爬虫、API、OC、gpx、web2cgeo 导入...

绝对地。 一想到要陆续切换到新的API，就没有想到OAuth认证。

@SammysHP ：爱丽丝在地羊仙境：

“当我使用一个词时，”矮胖子用一种相当轻蔑的语气说，“它的意思正是我选择的意思——不多也不少。”
“问题是，”爱丽丝说，“你能不能让词表达这么多不同的意思。”
“问题是，”矮胖子说，“谁才是主人——仅此而已。”

昨天我收到了 Groundspeak 的邮件：

亲爱的斯文，

感谢您在我们推进 Geocaching.com API 计划时的耐心等待。 随附两份文件供您查看。 请将填妥的 API 注册表格返回给我，我们将向您发送 API 测试密钥。

这个公共 API 计划的目标是允许受信任的第三方使用 geocaching.com 数据集开发应用程序和服务，该数据集主要服务于 Groundspeak 高级会员，同时还允许为基本会员提供大量服务。 该 API 将免费提供版税，以便开发人员可以在他们认为合适的情况下产生收入（或不产生收入），而无需向 Groundspeak 支付版税以获得数据访问权。

我们相信，这将使您能够最好地服务于更广泛的社区，包括新用户，同时为基本会员提供更多升级以获得完整高级服务的机会。 理想情况下，我们希望享受介绍性体验的会员升级到高级会员以获得完整的应用程序/服务访问权限。 有关此结构的具体细节包含在协议的附表 A 中。 在生产数据库访问和正式启动之前，需要同意这些条款并填写完整的 API 注册表格。

请注意，作为值得信赖的开发人员，我们希望您不会滥用 API，无论是在暂存阶段还是在生产阶段。 基本或高级会员的任何应用程序或服务都不允许从网站上抓取 geocaching.com 数据。 与其允许抓取，我们更愿意开发 API 调用以满足特定的开发人员需求。 如果您对计划使用 API 执行的潜在操作有任何疑问，请在 API 论坛中发布，我们将尽最大努力澄清规则。

启用 API 的应用程序/服务的所有用户都需要通过 Oauth 登录。 收到您填写的 API 注册表格后，我们将向您发送一个测试密钥，供您访问暂存服务器。 然后，在审查您的产品和功能后，我们将继续使用生产 API 密钥。

再次感谢你。 我们非常期待与您合作。

最好的祝福，

克里斯蒂

克里斯蒂·路德
业务发展经理
Groundspeak, Inc.
Groundspeak - 地点的语言
www.groundspeak.com
www.geocaching.com

这是 API 许可协议： http ://www.file-upload.net/download-3675937/Groundspeak-API-License-Agreement-17-08-2011.pdf.html

问题是密钥必须是公开的，因为每个开发人员都编译自己的构建（用于测试和使用）。 据我所知，这对 Groundspeak 来说是个问题。
所以我的建议是：等到连接器接口实现后，再开发使用 API 作为一个单独的应用程序。

嗨，我很快浏览了许可协议。 虽然我没有看到关于可能源自 4.17 或 4.18 的 API 密钥的明确保密请求。
扼杀外部连接器概念的可能是 4.16（衍生工作）和 5.3（最终用户 - 不是其他应用程序）。
将其集成到 c:geo 将违反 4.14。
基本会员限制是个笑话。
我投票赞成忽略它，直到他们提出一个合理的许可模型。

我认为，可以粘贴某人从 Bryan 那里收到的邮件：

你好 _________，

我们愿意提供对 CGeo Opensource 的 API 访问。 但是，由于许可证密钥只能用于单个应用程序，我们担心它可能会被公开共享。 如果它被公开共享，它可能被其他应用程序使用，这将导致 Groundspeak 被迫取消特定密钥。 当然，这会破坏应用程序，因为它无法访问数据。

那么，您能否帮助我了解您计划如何限制对身份验证密钥的访问？ 在任何情况下都不能公开发布。 由于有许多开发人员在从事开源项目，我们知道只需要一个开发人员向外部提供代码，然后我们都会遇到问题。 请提供您可以提供的任何信息，我们很乐意直接与您或项目的主要代表合作，以完成这项工作。

我在这封电子邮件中包含了 Christy Luther，因为她正在为第三方开发人员管理开发过程。

谢谢！

真挚地，

布莱恩

所以他们愿意帮助我们，但我的意见是等到（为了更好的集成，不那么严格的许可，也许是不需要密钥的 API，而只需要 OAuth 密钥）。

什么让我眼花缭乱：谷歌能够为他们的地图 api 管理这样的开发模型。 但地羊不能吗？ 奇怪。

谷歌有两件事：

• Google API 检查证书，应用程序已签名。 Groundspeak 的密钥应该适用于所有平台和编程语言。
• Google API 密钥是免费的，因此每个开发人员都可以获得一个。

我知道。 正是由于不同文化的碰撞，在这里引发了问题的是 groundsheep api 过程：St Jeremy 的僵化、苹果式的“离开我的球场”和谷歌擅长的开放式集市。它再也没有对比了。 至于与 Android 相关的部分：如果我没记错的话，那么您也可以使用 javascript web 应用程序中的谷歌地图，所以它们似乎有一个独立于平台的方法。 谷歌和groundsheep的思维方式不同导致了这些问题，谷歌不是邪恶的，但什么是groundsheep？

AFAIK JavaScript 的密钥检查域。

再看一次，这次是 OSM 基础设施：他们需要操作一个开放的环境，但要防止滥用他们的数据库。 他们不检查用于编辑 OSM 数据的应用程序：这应该如何解决？ 对于每一个新版本、补丁等等...... St Jeremy 是否想再次检查每一个应用程序？ 控制神经症，有人吗？ 因此，OSM 检查用户。 似乎不是问题。 也许我遗漏了一些东西，但是为什么 OSM 模型不适用于地理缓存数据呢？

当我听说新的公共 API 时，这就是我的想法。

如果每个开发人员都有自己的密钥，API 密钥的问题可能会得到解决——但是看看我投票反对使用 api 的基本会员的限制。

BFKC 正在与 Groundspeak 联系，所以让我们等待。 此外，实现 API 的唯一可能性是来自 GeOrg 的连接器： http ://android.ranitos.de/files/connector-sample.zip 我喜欢用于应用程序和连接器之间通信的方式。

同时，如果您想要 API 文档的链接，可以 PM 我。

暂时关闭它，我们将记住这一点，并在实现连接器接口时再次讨论它。 见#10

最终用户可能负责在 c:geo 中输入有效的用户密钥。 开发人员可以使用自己的用户密钥开发每个。

不，OAuth 需要应用程序的密钥。

是的，用于生成用户密钥的密钥。 然后用户密钥用于与 API 服务器通信。 用户如何/从哪里到达那里的关键取决于他们。

你说，我们应该为我们的目的使用另一个应用程序的帐户？！

如果只有一个开发人员获得密钥，会有什么问题？
必须有人负责将“官方”版本发布到谷歌商店。
因此，该开发人员会将 API 密钥添加到一些打包到 apk 中的配置文件中。
如果其他开发者想在代码的 API 部分工作，他们可以自己申请 API 访问！
想要使用自定义版本的 c:geo 的人显然需要自己的 API 密钥，但我认为大多数用户不想使用自定义版本。 在所有情况下，这总比没有 API 支持要好！

钥匙的问题只是一个小问题。 主要问题是，根据基础许可条款，您不得通过 API 以外的其他方式将缓存放入您的应用程序。
这意味着我们必须围绕 API 构建所有功能，使 c:geo 成为有效的高级应用程序。

好吧，关于这个问题的简短更新。

• API 许可协议链接： http ://www.geocaching.com/live/api_license_agreement.aspx
• GeOrg 有一个新的连接器，通过 API 提供 gc.com 访问：https: //play.google.com/store/apps/details? id=georg.connector.gcapi
  我正在与开发人员联系，这并不像看起来那么容易。 我不能在公共场合说太多。
• Locus 有一个插件，geocaching4locus：http: //geocaching4locus.eu/
  它还为基本会员和高级会员（通过 API）提供访问权限。 但现在却被 Groundspeak 挡住了：

尊敬的用户，

正如你们中的一些人所知，我们试图为具有相同限制的基本和高级会员提供服务。 因此，我们违反了基本成员的 Geocaching API 许可协议。 不幸的是，Groundspeak, Inc.（负责管理 Geocaching.com 网站的公司）发现了我们的行为，我们被迫暂停在 Google Play 和其他应用商店中分发我们的应用程序。 你们中的一些人可能在过去几天遇到了登录问题，这可能与此有关。

想了很久，我们决定把我们的申请合法化，可惜影响了基础会员。 因为根据本许可协议，基本成员每天只能下载三个完整的 Geocaches。 这就是为什么我们做我们以前做的事情的原因。 高级会员的限额与以前相同，每天 6 000 个 Geocaches。

由于本许可协议要求的基本成员添加了确认对话框，因此适应新规则需要几天时间。 我希望我们能尽快发布一个新版本，即使以不完整的翻译为代价。

Geocaching4Locus 开发团队

假设 c:geo 能够从 Groundspeak 获得 API 访问权限：

1. 现有API 许可协议的哪些要点需要讨论和/或修改以符合我们的要求？
2. 如果我们更改 API 是否可以保留所有现有功能，或者 API 需要进行哪些技术修改才能实现这一点？ 我通过谷歌找到了这个帮助页面，但不知道这是否反映了当前的 API。

另见IRC 日志 18.05.2015

地位：
致 Bryan 的信已发送（可在 Googlegroups 邮件列表中的开发团队中找到）。
等待反馈。

仅供进一步参考，以防有人热衷于查看它如何与 c:geo 工作模式匹配：
https://api.groundspeak.com/LiveV6/geocaching.svc/help

@Lineflyer我不信任文档中字体大小不同的 API。

我想说的不是真正的文档，而是从代码注释自动生成的东西。
单击链接会发现更多让我不寒而栗的事情（Tucson.Geocaching.WCF.API.Geocaching.Types）。
看起来他们并没有真正设计他们的 API，而是使用框架来生成和公开一些东西......

你好，

此 API 将于 2019 年 5 月 1 日弃用，但几个月以来新的 REST API 正在生产中，回调 URL 需要得到 Groundspeak 的授权。 因此，即使知道密钥，也没有人可以使用它，因为 GS 会重定向到回调 URL。

（我有权访问此 API）。

• 开发人员文档 - https://api.groundspeak.com/documentation
• Swagger 文档 - https://api.groundspeak.com/api-docs/index

我很害怕，这个问题不是最新的。 同时，c:geo 核心团队开发人员可以访问最新的 API（暂存环境），并且文档也可用。
如果您有兴趣提供帮助，我们需要澄清您需要什么并提供适当的访问权限

我想帮助你，但我是 web 开发人员 (php/go)，而不是 Android Dev..

更新此问题：我们与 Groundspeak 联系了很长时间，评估我们如何使用 API。 仍有一些未解决的（非技术性）问题需要解决，但我们已经收到了新 API 的开发密钥。 作为下一步，我们必须设计与 c:geo 的集成（例如，如果它只是一个新的连接器，或者是否需要进行其他更改）。 对于那个和以下实施阶段，任何帮助表示赞赏。

过去，Groundspeak API 的某些使用条款存在问题（任何人都无法或难以获得用于开发目的的密钥，检索到的缓存数量及其对基本成员的 D/T 等级的每日严格限制，无法显示缓存来自诸如 opencaching 之类的并发网站……），这些问题是否已解决，还是您提到的这些非技术性剩余问题？
我没有看到 Groundspeak 改变他们对他们的商业模式和他们（缺乏）开放性的想法，看到他们当前的 API限制。

好吧，Groundspeak 表示愿意讨论这个非技术问题，我们已经提出了一些建议。 然而，为了进一步讨论这一点，我们可能需要了解 API 使用与使用流程中当前实现之间的影响/差异。

我不想在这个开放的论坛上提供任何细节，但是我们肯定会让任何愿意参与 API 实现工作的人参与这次讨论，并在最终决定之前让我们的用户参与进来。

这里有什么新东西吗？ 我之前涉足过 API，实现起来还不错。 还看了他们现在的新版本。
问题是：有人领导这个话题吗？
我觉得这对 c:geo 来说可能是一个很大的推动力。
有什么技术支撑？

有什么技术支撑？

基本上是人力。

但在使用条款方面仍有一些悬而未决的问题。 因此，如果与 Groundspeak 没有协议，很有可能不会以当前形式使用技术实现，或者根本不会使用。

我认为我们应该从某种抽象的需求分析开始，然后在 c:geo 中列出受影响的区域和必要的更改。

没有技术上的阻碍。 不过，Api 是否能够承载我们现在拥有的所有功能，还需要仔细检查。
从我个人的角度来看，基本成员的 Api 使用缺乏资源和可接受的协议。
顺便说一句：你认为 c:geo 在这个话题中的提升在哪里？ 在开发资源方面会有点“便宜”，并且为 groundspeak 服务 c:geo 用户会更便宜，但除此之外呢？ 我没有看到 c:geo 将 Api 用于“平均乔”的任何大优势。 高级用户当然还有其他涉及 GSAK 和插入该链的移动工具的工作流程。