Hi wrygiel,
now i have read your documentation at
http://opencaching.pl/okapi/Very well documented, good work! Function list is good selected for the beginning and the specification of fields-list is a good choice to reduce unwanted traffic.
Next step is to test the okapi-code on the new GIT-code.
Below is the list of my thoughts, while i have read the documentation. None of it is realy critical and i think you have realy done a good job. The only thing we should talk about is the is_admin-flag for the user.
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. Installing a new virtual host with PHP 5.3 requirement but not move the oc.de-production-server to it will be easier. If required, i could map the oc-htdocs with NFS to that host.
We could add a service-locator-info-file e.g.
http://www.opencaching.de/okapi.xml. Inside this file, we can redirect to other host e.g. okapi.opencaching.de/... or
http://www.opencaching.de/okapi/... That could also simplify future upgrades, host-reinstallations and load-balancing.
Once i have time for migration, i willl then move the production oc-source to the new installed virtual host ...
Kind regards,
Oliver
-----
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.
- rating ... as i know, oc.pl has different rating system. recommendations sounds like the one we have.
- 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.
services/caches/formatters
- gpx ... Do you use search.gpx.inc.php for formatting or do you have own code?
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
- size ... "caches with no container" could be size=0
- radius in /nearest ... we have a limit of 150km because calculation gets unefficient - then the developer should switch to bbox.
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.
- submit ... why dont allow HTML logs?
serice/users/user
- is_admin ... this should only be querable for the own user account for security reason. Also note that we have split admin priviledges into different levels.