Cgeo: API-интерфейс Geocaching.com

Это, конечно, должно быть согласовано с #9...

где новый апи?? Я думаю, что если есть API, который поддерживает все функции, мы должны его использовать. (но только в том случае, если Groundpeak немедленно изменит API, если они сделают обновление на geocaching.com)

API доступен только для избранных приложений. Cgeo был один, cgeo с открытым исходным кодом - нет

Я надеюсь, что они не меняют API при каждом изменении веб-страниц...
В противном случае мы могли бы продолжать сканировать страницы и обновлять наш код при каждом изменении, которое GC.com вносит в свои веб-страницы...
Я читал, что API теперь будет доступен как для премиальных, так и для базовых участников с некоторыми ограничениями для базовых членов.
Если вы не возражаете, я свяжусь с Райаном из Groundspeak и попрошу у него документацию по API.
Флориан.

У нас есть документ, но у нас нет ключа доступа к API

Несколько недель назад я прочитал уведомление о предстоящем API. У кого-нибудь есть еще указатели?

:( Я имел в виду, что они обновляют библиотеку после изменений на gc.com :D

Поэтому, если вы не возражаете, я бы попросил у Groundspeak ключ доступа к API для c-geo (а также уточнил у Groundspeak, что c-geo-opensource в основном такой же, как c-geo, только с разъяснением о лицензировании открытого исходного кода). ).
Можете ли вы прислать мне копию документации или, если она есть где-то в Интернете, дать мне ссылку на нее?
Флориан.

Сэмми общался. Давай подождем его

Я связался с ними несколько недель назад. В ответе была одна строка, в которой мне было сказано отправить им заявку на доступ к API. Похоже, общедоступной документации нет, вам нужен API-ключ для приложения, и каждый пользователь должен получить ключ через OAuth-процедуру. И они называют это "общедоступным API"...

Я думаю, что мы не должны жестко кодировать это. С коннектором-интерфейсом будет проще, так что не имеет значения, если мы будем импортировать из спайдеринга, API, OC, gpx, web2cgeo...

Абсолютно. Я не думал об аутентификации OAuth, когда думал о последовательном переходе на новый API.

@SammysHP : Алиса в стране чудес овец:

«Когда я использую слово, — сказал Шалтай-Болтай довольно презрительным тоном, — оно означает именно то, что я выбираю, — ни больше, ни меньше».
«Вопрос в том, — сказала Алиса, — можно ли заставить слова означать так много разных вещей».
-- Вопрос в том, -- сказал Шалтай-Болтай, -- кто должен быть хозяином -- вот и все.

Вчера я получил письмо от Groundspeak:

Дорогой Свен,

Спасибо за ваше терпение, поскольку мы продвигаемся вперед с Программой API Geocaching.com. Прилагаю два документа для ознакомления. Пожалуйста, верните мне заполненную регистрационную форму API, и мы вышлем вам тестовый ключ API.

Цель этой общедоступной программы API — позволить доверенным третьим сторонам разрабатывать приложения и услуги с использованием набора данных geocaching.com, которые будут в первую очередь обслуживать участников Groundspeak Premium, а также предоставлять значительный объем услуг участникам Basic. API будет предоставляться бесплатно, чтобы разработчики могли получать доход (или нет) по своему усмотрению, без необходимости платить роялти Groundspeak за доступ к данным.

Мы считаем, что это даст вам возможность наилучшим образом обслуживать более широкое сообщество, в том числе новых пользователей, а также предоставит дополнительные возможности для базовых участников перейти на полные услуги Premium. В идеале, мы хотели бы, чтобы участники, которым нравится ознакомительный опыт, могли перейти на Премиум-членство, чтобы получить полный доступ к приложениям/услугам. Конкретные сведения об этой структуре содержатся в Приложении А к Соглашению. Согласие с Условиями и заполненная форма регистрации API потребуются до доступа к рабочей базе данных и официального запуска.

Обратите внимание, что как доверенный разработчик мы рассчитываем, что вы не будете злоупотреблять API ни на этапе подготовки, ни в рабочей среде. Очистка веб-сайта для данных geocaching.com не разрешена ни в одном приложении или сервисе для базовых или премиальных участников. Вместо того, чтобы разрешать парсинг, мы бы предпочли разработать вызовы API для удовлетворения конкретных потребностей разработчиков. Если у вас есть какие-либо вопросы относительно возможных действий, которые вы планируете совершать с API, задайте их на форумах API, и мы сделаем все возможное, чтобы прояснить правила.

Вход через Oauth потребуется для всех пользователей приложений/служб с поддержкой API. После получения заполненной формы регистрации API мы вышлем вам тестовый ключ для доступа к промежуточному серверу. Затем, после рассмотрения вашего продукта и его функциональных возможностей, мы перейдем к ключу производственного API.

Еще раз спасибо. Мы очень надеемся на сотрудничество с вами.

С наилучшими пожеланиями,

Кристи

Кристи Лютер
Менеджер по развитию бизнеса
Граундспик, Инк.
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 в качестве отдельного приложения.

Привет, я вкратце просмотрел лицензионное соглашение. Хотя я не вижу явного запроса на конфиденциальность в отношении ключа API, который, возможно, может быть получен из 4.17 или 4.18.
Что убивает концепцию внешнего соединителя, так это, вероятно, 4.16 (производная работа) и 5.3 (конечные пользователи, а не другие приложения).
Интеграция его в c:geo нарушила бы 4.14.
Базовые лимиты участников — это шутка.
Я голосую за то, чтобы просто игнорировать это, пока они не придумают разумную модель лицензирования.

Я думаю, можно вставить письмо, полученное от Брайана:

Привет _________,

Мы готовы предоставить API-доступ к CGeo Opensource. Однако, поскольку лицензионный ключ должен использоваться только для отдельного приложения, мы обеспокоены тем, что он может стать общедоступным. Если он будет опубликован публично, он может быть использован другими приложениями, и это приведет к тому, что Groundspeak будет вынужден отменить конкретный ключ. Это, конечно, сломает приложение, потому что оно не сможет получить доступ к данным.

Итак, не могли бы вы помочь мне понять, как вы планируете ограничить доступ к ключу аутентификации? Ни при каких обстоятельствах он не может быть обнародован. Поскольку над проектом с открытым исходным кодом работает несколько разработчиков, мы знаем, что достаточно одного разработчика, чтобы предоставить внешний код, и тогда у всех нас возникнут проблемы. Пожалуйста, предоставьте любую информацию, которую вы можете, и мы будем рады работать непосредственно с вами или главным представителем проекта, чтобы сделать эту работу.

Я включил Кристи Лютер в это электронное письмо, так как она управляет процессом разработки для сторонних разработчиков.

Спасибо!

Искренне,

Брайан

Так что они готовы помочь нам, но также мое мнение - подождать до тех пор, пока (для лучшей интеграции, менее строгой лицензии, может быть, API, которому не нужен ключ, а только ключ OAuth).

что меня поражает: Google умеет управлять такими моделями разработки для своих карт API. А овцы не могут? странный.

В Google есть две вещи:

• Google API проверяет сертификат, которым приложение подписано. Ключ от Groundspeak должен работать с любой платформой и языком программирования.
• Ключ API Google бесплатен, поэтому каждый разработчик может его получить.

Я знаю. Это процесс API-интерфейса овцы, который вызывает проблемы здесь, поскольку сталкиваются разные культуры: жесткое, похожее на яблоко «уйди с моего двора» Святого Джереми и похожее на открытый базар, в котором силен Google. Это не может быть больше контраста. Что касается части, зависящей от Android: если я правильно помню, вы также можете использовать карты Google из веб-приложений javascript, поэтому у них, похоже, есть независимый от платформы метод. Это разное мышление между Google и Groundsheep вызывает сбои, Google не будь злым, но что такое Groundsheep?

AFAIK ключ для JavaScript проверяет домен.

Взгляните еще раз, на этот раз на инфраструктуру OSM: им нужно работать в открытой среде, но при этом защищать свою базу данных от неправомерного использования. Они не проверяют приложения для редактирования данных OSM: как это вообще должно работать? С каждым новым релизом, патчем и так далее... Святой Джереми хочет снова проверять каждое приложение? Кто-нибудь контролирует невроз? Итак, OSM проверяет пользователей. Кажется, это не проблема. Может быть, я что-то упускаю, но тогда почему модель OSM не работает для данных геокэшинга?

Это были мои мысли, когда я услышал о новом общедоступном API.

Проблема с ключом API может быть решена, если каждый разработчик получит свой собственный ключ, но, глядя на ограничения для базовых членов, я голосую против использования API.

BFKC связывается с Groundspeak, так что давайте подождем. Также единственная возможность реализовать API — это коннектор вроде того, что есть в GeOrg: http://android.ranitos.de/files/connector-sample.zip Мне нравится способ, который используется для связи между приложением и коннектором.

А пока вы можете написать мне в личку, если вам нужна ссылка на API-документацию.

Закрывая это на данный момент, мы запомним это и поговорим об этом снова, когда интерфейс коннектора будет реализован. См. № 10

Конечный пользователь может нести ответственность за ввод действительного ключа пользователя в c:geo. Разработчики могут разработать каждый с собственным пользовательским ключом.

Нет, для OAuth требуется секретный ключ для приложения.

Да секретный ключ для создания пользовательского ключа. Затем пользовательский ключ используется для связи с сервером API. Как / где пользователь получит ключ, зависит от них.

Вы говорите, мы должны использовать учетную запись другого приложения для наших целей?!

В чем проблема, если только один разработчик получает ключ?
Должен быть кто-то, кто отвечает за выпуск «официальных» выпусков в магазине Google.
Таким образом, этот разработчик добавит ключ API в некоторый файл конфигурации, который будет упакован в apk.
Если другие разработчики хотят работать над частью кода API, они могут сами подать заявку на доступ к API!
Людям, которые хотят использовать пользовательские версии c:geo, очевидно, потребуется собственный ключ API, но я думаю, что большинство пользователей не хотят использовать пользовательские версии. Во всех случаях это лучше, чем полное отсутствие поддержки API!

Вопрос о ключе — это лишь незначительная проблема. Основная проблема заключается в том, что в соответствии с условиями лицензирования вы не должны получать кэши в свое приложение другими способами, кроме API.
Это означало бы, что мы должны были построить всю функциональность вокруг API, сделав c:geo фактически приложением только для премиум-класса.

Итак, небольшое обновление по этому вопросу.

• Ссылка на лицензионное соглашение API: http://www.geocaching.com/live/api_license_agreement.aspx
• Появился новый коннектор для GeOrg, обеспечивающий доступ к gc.com через API: https://play.google.com/store/apps/details?id=georg.connector.gcapi .
  Я на связи с разработчиком, и это не так просто, как кажется. Я не могу много говорить об этом публично.
• Был плагин для Locus, geocaching4locus: http://geocaching4locus.eu/
  Он предоставил доступ также для базовых участников и дополнительно для премиум-членов (через API). Но теперь его заблокировал Groundspeak:

Уважаемые пользователи,

Как некоторые из вас знают, мы пытались предоставить услуги для базовых и премиум-членов с одинаковыми ограничениями. Таким образом, мы нарушили Лицензионное соглашение API геокэшинга для базовых участников. К сожалению, Groundspeak, Inc. (компания, занимающаяся сайтом Geocaching.com) обнаружила наши действия, и мы были вынуждены временно приостановить распространение нашего приложения в Google Play и других магазинах приложений. Некоторые из вас, вероятно, испытывали проблемы со входом в систему в последние несколько дней, что может быть связано с этим.

После долгих размышлений мы решили легализовать наше приложение, но, к сожалению, это касается основных участников. Поскольку базовые участники ограничены загрузкой трех полных тайников в день в соответствии с этим лицензионным соглашением. Это было причиной, почему мы делали то, что делали раньше. Для премиум-пользователей ограничение будет таким же, как и раньше, 6 000 тайников в день.

Адаптация к новым правилам займет несколько дней из-за добавления диалогов подтверждения для основных участников, которые требуются по данному лицензионному соглашению. Я надеюсь, что мы выпустим новую версию как можно скорее, даже ценой неполных переводов.

Команда разработчиков Geocaching4Locus

Предполагая, что c:geo сможет получить доступ к API от Groundspeak:

1. Какие пункты существующего лицензионного соглашения API необходимо обсудить и/или изменить, чтобы они соответствовали нашим требованиям?
2. Можем ли мы сохранить все существующие функции, если перейдем на API, или какие технические изменения потребуются для достижения этого в API? Я нашел эту страницу справки через Google, но не знаю, отражает ли это текущий API.

См. также журнал IRC от 18 мая 2015 г.

Статус:
Письмо Брайану отправлено (доступно для команды разработчиков в списке рассылки Googlegroups).
Ждем отзывов.

Просто для дальнейшего справки и на случай, если кто-то захочет посмотреть, как это будет соответствовать рабочему режиму c: geo:
https://api.groundspeak.com/LiveV6/geocaching.svc/help

@Lineflyer Я не доверяю API, у которых в документации разные размеры шрифтов.

Я бы сказал, что это не настоящая документация, а нечто, автоматически сгенерированное из комментариев к коду.
Щелчок по ссылке открывает еще больше вещей, которые заставляют меня слегка вздрогнуть (Tucson.Geocaching.WCF.API.Geocaching.Types).
Похоже, они на самом деле не разрабатывают свой API как таковой, а используют фреймворк для создания и демонстрации чего-то...

Привет,

Этот API станет устаревшим 1 мая 2019 года, но новый REST API находится в разработке уже несколько месяцев, и URL-адрес обратного вызова должен быть авторизован Groundspeak. Таким образом, даже если ключи известны, никто не может их использовать, потому что GS будет перенаправлять на URL-адрес обратного вызова.

(У меня есть доступ к этому API).

• Документация для разработчиков — https://api.groundspeak.com/documentation
• Документация Swagger — https://api.groundspeak.com/api-docs/index

Боюсь, этот вопрос не актуален. В то же время у разработчиков c:geo core есть возможность получить доступ к последнему API (промежуточной среде), а также доступна документация.
Если вы заинтересованы в помощи, нам нужно уточнить, что вам для этого нужно, и предоставить соответствующий доступ.

Я хотел бы вам помочь, но я веб-разработчик (php/go), а не Android Dev..

Чтобы обновить эту проблему: мы давно общаемся с Groundspeak, оценивая, как мы можем использовать API. Есть еще некоторые открытые (нетехнические) проблемы, которые нужно решить, но мы уже получили ключи разработки для нового API. В качестве следующего шага мы должны спроектировать интеграцию с c:geo (например, если это просто новый коннектор или если необходимы другие изменения). Для этого и следующего этапа реализации приветствуется любая помощь.

Некоторые условия использования API Groundspeak в прошлом были проблематичными (невозможность или трудности с получением ключей для целей разработки для всех, кто спрашивал, резкие ежедневные ограничения на количество извлекаемых кешей и их рейтинги 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 и мобильные инструменты, которые подключаются к этой цепочке.