> Another question: Does the API code require access to the real
> OC.de-source e.g. with the current upload-images-directory or is it
> possible to install the API on a second webserver? We have virtual
> server infrastructure with 2 physical hosts.
Currently, OKAPI is a plugin for OC code. It is not a standalone
application. It could be made standalone, but I am not sure if this is
a good way to go. Currently OKAPI may take advantage of the existing
OC code.
Are you quite sure making OKAPI a standalone app is a good idea?
On the other hand, relaying on existing code might be a mistake.
> services/caches/geocache
>
> - founds/notfounds ... we have a table stat_caches, so you dont
> need to recalculate these values each time. I am not sure if this
> table was introduced before or after oc-pl-merge.
I don't recalculate either, we have caches.founds and caches.notfounds
fields.
> - rating ... as i know, oc.pl has different rating system.
> recommendations sounds like the one we have.
This could be troublesome. I thought the rating system will be a
common between all OC installations. You will probably have to create
a patch for OKAPI with some "site-specific conditions".
> - images ... we have a is_hidden-flag. A user may add images that
> are only referenced in HTML for decoration. These images should not
> be shown in the image list, but may be downloaded to decorate the
> html properly.
Have you checked the OKAPI code? Here is the query I use:
http://code.google.com/p/opencaching-api/source/browse/trunk/okapi/services/caches/geocaches.php?r=80#160Aren't you talking about the "display" column?
> services/caches/formatters
>
> - gpx ... Do you use search.gpx.inc.php for formatting or do you
> have own code?
My own:
http://code.google.com/p/opencaching-api/source/browse/trunk/okapi/services/caches/formatters/gpx.php?r=80http://code.google.com/p/opencaching-api/source/browse/trunk/okapi/services/caches/formatters/gpxfile.tpl.php?r=80> services/caches/search
>
> - all ... because of timeouts, memory limits or mysql locking
> issues, i think returning realy all geocaches is not a good idea. I
> dont tested it, so it may work good, but i think having no limit
> given will result to failures in future, so the API signatures
> should handle this from beginning ... could you use the LIMIT-syntax
> of mysql with start-parameter? e.g. SELECT * FROM caches ORDER BY
> wp_oc LIMIT 1000, 100
I do not return all of them. There is a limit of 500 (100 by default).
The docs were misleading.
> - size ... "caches with no container" could be size=0
Added a new issue:
http://code.google.com/p/opencaching-api/issues/detail?id=52> - radius in /nearest ... we have a limit of 150km because
> calculation gets unefficient - then the developer should switch to
> bbox.
How inefficient? Why?
Actually, I don't like the limit. If it turned out to be inefficient,
I would try to think of some heuristics to cope with that.
> services/logs
>
> - logs should also include any limit and start-parameter. E.g. a
> smartphone-application that shows the latest logs from
> caches/geocache and has a "show more" button. Show-more will show
> the next 10 logs. If the smartphone receives all logs of the caches,
> traffic may be too much. Our cache with most finds at oc.de has 750
> finds (i've seen some at gc.com with >3000). Average log text length
> at oc.de is 300 chars. With suername, uuid and other infos, average
> bytes per log will be 400 bytes. 400 byte * 700 are 280 kByte in worst case.
You're right. But I will probably have to make this parameter
optional.
http://code.google.com/p/opencaching-api/issues/detail?id=53> - submit ... why dont allow HTML logs?
http://code.google.com/p/opencaching-api/issues/detail?id=54> serice/users/user
>
> - is_admin ... this should only be querable for the own user account
> for security reason.
Why? Identities of admins are hidden?
Currently I use this only in one place:
http://code.google.com/p/opencaching-api/source/browse/trunk/okapi/services/logs/submit.php?r=80#78> Comment from germany end user forum:
>
http://www.geoclub.de/viewtopic.php?p=907982>
> bbox in format W,S,E,N would be compatible with OpenStreeMap-XAPI
I can't change it now. 2 days ago OKAPI was officially released. Now
we have to be backward-compatible.
> The API also responds with this code, when i dont specify cache_code
> in caches/geocache-call Maybe you can choose another code?
No. Have you ever used some APIs? The 400 code is a standard "bad
request" response. Both of these requests are "bad requests".
> Is there any way to validate the comsumer_key? The response of the
> service is the same when i have invalid consumer_key or invalid
> cache_code.
Which service? Does this service require authentication?