Hi,
Many users and developers application ask us about exist API with OC. I have looking how to built API REST for OC after review many descriptions about how to create own API REST I have found light framework and good descriptions bout how create own API RESFul use http://codeigniter.com/
I have spent a few days and run API REST in this moment read only but you can see how this working. It is not production version becasue not all working and I have setup API-Key only one but in final version every user who is registered they can in own profile generate own API-Key to use this API.
Description of API:
http://opencaching.pl/services/
API generate outputs default in GPX but you can add param &format=xxx where xxx can:
XML, JSON GPX
http://opencaching.pl/services/api/cache?wp=OP26CB&logs=5&api-key=xxxxx
http://opencaching.pl/services/api/cache?point=18.5,53.0&dist=25&limit=10&logs=5&api-key=xxxxx
where api-key you must generate for own user registered on OC PL call: http://opencaching.pl/api_keys.php
At current it is only for test not public version on OC PL
If anybody interested this you can download package from:
Descriptions pages are in services/applications/views
main controller are in services/applications/controllers/api/
modules for controllers services/applications/models/
You can easy setup in services/applications/config/database setup username/password to connect OC DB. Package you can restore in main dir OC
CI include in API REST suport OAuth v2.0 and we can setup use OAuth with API REST (I did not try use this)
Package contain tutorial CI (link in on bootom opencaching.pl/services/)
You can download package from https://github.com/sp2ong/API-REST-OCPL-Node
It is only proposition. At curret I don't have more time spent to tune API REST but maybe it is good point to start create API REST in OC Sites.
API REST
Hello!
On Oc.de i will create a restapi.
The current discussion is about the authentification-system.
We have 2 systems:
First: The developer has to register his application, so we can identify the app (with a token) and the user (user login data has to send, too).
Second: A Session based System. When an app create a session, the app give app data (like author, name, version) and user data (like username and password) to the oc.de server and the server send a sessionid back. The session is coupled with a cookie and the client ip.
One advantage of the first system is, that we can ban an app (alternatively a version of an app) from the system.
Greetings.
solar22
Edit: I cannot open your archive
On Oc.de i will create a restapi.
The current discussion is about the authentification-system.
We have 2 systems:
First: The developer has to register his application, so we can identify the app (with a token) and the user (user login data has to send, too).
Second: A Session based System. When an app create a session, the app give app data (like author, name, version) and user data (like username and password) to the oc.de server and the server send a sessionid back. The session is coupled with a cookie and the client ip.
One advantage of the first system is, that we can ban an app (alternatively a version of an app) from the system.
Greetings.
solar22
Edit: I cannot open your archive
(On debian, tgz archives will be open with "tar")tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
Ok fine, It is my short work (a few days) with CI framework and it is look is very useful to create API RESTFul with API-Key and OAuth system but any solution API REST on OC will be good if will be avilable to users and dvelopers. One other our developer want to creata API RESt base on Phyton language but I know only PHP for this reason I have look any tool which help to do API REST base on PHP
Hm I have make again apirest.tgz you can rename this for apirest.tar.gz before restore or make step by step
gzip -d apirest.tgz
tar xvf apirest.tar
Regards
Hm I have make again apirest.tgz you can rename this for apirest.tar.gz before restore or make step by step
gzip -d apirest.tgz
tar xvf apirest.tar
Regards
I think a framework is a little bit to big for a rest api
The functions to load a cache from database, or to do anything else, already exists.
We only have to load this function with the parameters.
When in the current oc.de code aren't any functions, so we have to create new.
So on maintenance, you only have to edit one function and not 2 or 3 files.
You know, what i mean?
The functions to load a cache from database, or to do anything else, already exists.
We only have to load this function with the parameters.
When in the current oc.de code aren't any functions, so we have to create new.
So on maintenance, you only have to edit one function and not 2 or 3 files.
You know, what i mean?
[quote="sp2ong"]
Hi,
Many users and developers application ask us about exist API with OC.
[/quote]
Do you mean an API to let developers create non-browser applications which interacts with OC database? Do you suppose read-only access or read-write one?
Hi,
Many users and developers application ask us about exist API with OC.
[/quote]
Do you mean an API to let developers create non-browser applications which interacts with OC database? Do you suppose read-only access or read-write one?
[quote="solar22"]
We have 2 systems:
First: The developer has to register his application, so we can identify the app (with a token) and the user (user login data has to send, too).
Second: A Session based System. When an app create a session, the app give app data (like author, name, version) and user data (like username and password) to the oc.de server and the server send a sessionid back. The session is coupled with a cookie and the client ip.
One advantage of the first system is, that we can ban an app (alternatively a version of an app) from the system.
[/quote]
I think the spirit of Opencaching is being open. I do not like an idea to register an application.
What the purpose of banning an application (not a user)?
We have 2 systems:
First: The developer has to register his application, so we can identify the app (with a token) and the user (user login data has to send, too).
Second: A Session based System. When an app create a session, the app give app data (like author, name, version) and user data (like username and password) to the oc.de server and the server send a sessionid back. The session is coupled with a cookie and the client ip.
One advantage of the first system is, that we can ban an app (alternatively a version of an app) from the system.
[/quote]
I think the spirit of Opencaching is being open. I do not like an idea to register an application.
What the purpose of banning an application (not a user)?
When an application for example download a mass of data or will sabotage the api or oc, so we can block/ban the application token and the application cannot grab more data.
[quote="Van de Bugger"]
What the purpose of banning an application (not a user)?
[/quote]
1) We have a list of all applications and can link to their website, inform the developers of API changes etc.
2) If an application has a bug inside, we have the chance to block that application. In the past we had several probems with OC prop which resulted in false listings and logs.
What the purpose of banning an application (not a user)?
[/quote]
1) We have a list of all applications and can link to their website, inform the developers of API changes etc.
2) If an application has a bug inside, we have the chance to block that application. In the past we had several probems with OC prop which resulted in false listings and logs.
[quote="oliver"]
In the past we had several probems with OC prop which resulted in false listings and logs.
[/quote]
Sorry, did not get it.
Is registering should be complete before accessing the data? Is it mandatory or optional?
I personally do not like an idea to register before I write a working code. However, I would agree if read-only access could be done without registering, but read-write access requires registration.
In the past we had several probems with OC prop which resulted in false listings and logs.
[/quote]
Sorry, did not get it.
Is registering should be complete before accessing the data? Is it mandatory or optional?
I personally do not like an idea to register before I write a working code. However, I would agree if read-only access could be done without registering, but read-write access requires registration.
[quote="Van de Bugger"]Is registering should be complete before accessing the data? Is it mandatory or optional?[/quote]
I think its mandatory. And i also think that it is standard in web apis. For google maps you had to create a key for a long time. Garmin communicator requires it, too.
Registration has 2 advantages for us:
1) The developer must agree our terms of use. So he cannot say "didn't know that i am not allowed to sell the listings i received with that API, i just copied the code from somewhere".
2) We can analyze failures, find performance bottlenecks and know if a single application is taking all our server capacity
We dont want to associate any usage fee or block applications just because they compete with features on our own website.
What is the disadvantage of registration?
I dont think that a developer has a problem with that if he is realy interested in it.
I think its mandatory. And i also think that it is standard in web apis. For google maps you had to create a key for a long time. Garmin communicator requires it, too.
Registration has 2 advantages for us:
1) The developer must agree our terms of use. So he cannot say "didn't know that i am not allowed to sell the listings i received with that API, i just copied the code from somewhere".
2) We can analyze failures, find performance bottlenecks and know if a single application is taking all our server capacity
We dont want to associate any usage fee or block applications just because they compete with features on our own website.
What is the disadvantage of registration?
I dont think that a developer has a problem with that if he is realy interested in it.