The OKAPI Project
:: OpenCaching API Reference
OKAPI is a public API project for National OpenCaching sites (also known as
OpenCaching Nodes).
- It provides OC site with a set of useful well-documented API methods,
- Allows external developers to easily read public OpenCaching data,
- Allows read and write private (user-related) data with OAuth 3-legged authentication.
The project is aiming to become a standard API for all National OpenCaching.xx sites.
This OKAPI installation provides API for the
http://www.opencaching.us/ site.
Check out other OKAPI installations:
And also:
How can I use OKAPI?
We assume that you're a software developer and you know the basics.
OKAPI is a set of simple (REST) web services. Basicly, you make a proper HTTP request,
and you receive a JSON-formatted data, that you may parse and use within your own application.
Example. Click the following link to run a method that prints out the list of
all available methods:
You've made your first OKAPI request! This method was a simple one.
It didn't require any arguments and it didn't require you to use a Consumer Key.
Other methods are more complex and require you to use
your own API key.
Authentication Levels
Each OKAPI method has a minimum authentication level.
This means, that if you want to call a method which requires "Level 1"
authentication, you have to use "Level 1" authentication or higher
("Level 2" or "Level 3" will also work).
Important: Most developers will only need to use "Level 1" authentication
and don't have to care about OAuth.
-
Level 0. Anonymous. You may call this method with no extra
arguments.
some_method?arg=44
-
Level 1. Simple Consumer Authentication. You must call this
method with consumer_key argument and provide the key which has
been generated for your application on the Sign up page.
some_method?arg=44&consumer_key=a7Lkeqf8CjNQTL522dH8
-
Level 2. OAuth Consumer Signature. You must call this method
with proper OAuth Consumer signature (based on your Consumer Secret).
some_method
?arg=44
&oauth_consumer_key=a7Lkeqf8CjNQTL522dH8
&oauth_nonce=1987981
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1313882320
&oauth_version=1.0
&oauth_signature=mWEpK2e%2fm8QYZk1BMm%2fRR74B3Co%3d
-
Level 3. OAuth Consumer+Token Signature. You must call this method
with proper OAuth Consumer+Token signature (based on both Consumer Secret and
Token Secret).
some_method
?arg=44
&oauth_consumer_key=a7Lkeqf8CjNQTL522dH8
&oauth_nonce=2993717
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1313882596
&oauth_token=AKQbwa28Afp1YvQAqSyK
&oauth_version=1.0
&oauth_signature=qbNiWkUS93fz6ADoNcjuJ7psB%2bQ%3d
GET or POST?
Whichever you want. OKAPI will treat GET and POST requests as equal.
You may also use the HTTP Authorization header for passing OAuth arguments.
OKAPI does not allow usage of PUT and DELETE requests.
Most of the methods return simple objects, such as lists and dictionaries
of strings and integers. Such objects can be formatted in several ways using
common formatting parameters (supplied by you along all the other
parameters required for the method to run):
Important: Almost all of the returned datatypes are extendible. This means,
that (in future) they may contain data that currently they don't.
Such data will be included in backward-compatible manner, but still you should remember about
it in some cases (i.e. when iterating over attributes of an object). This additional data may
appear as extra elements in GPX files or extra keys in JSON responses.
Your software must ignore such occurances if it doesn't understand them!
Some methods expose some special formatting of their own, for example, they may return
a JPEG or a GPX file. Such methods do not accept common formatting parameters.
OAuth Dance URLs
If you want to use Level 3 methods, you will have to make "the OAuth dance" (series of
method calls and redirects which provide you with an Access Token).
The three OAuth request URLs defined in the OAuth specification are:
Things you should pay attantion to:
-
The oauth_callback argument of the request_token method is required.
As the OAuth 1.0a specification states, it should be set to "oob" or a callback URL
(this usually starts with http:// or https://, but you can use any other myapp:// scheme).
For most OAuth client libraries, you just should provide
"http://www.opencaching.us/okapi/services/oauth/request_token?oauth_callback=oob"
as the request_token URL, to get it started. Later, probably you'd want to switch "oob"
to something more useful.
-
The oauth_verifier argument of the access_token method is also required.
When user authorizes your application, he will receive a PIN code (OAuth verifier). You
have to use this code to receive your Access Token.
-
Access Tokens do not expire (but can be revoked). This means, that once the user
authorizes your application, you receive a "lifetime access" to his/her account.
User may still revoke access to his account from your
application - when this happens, you will have to redo the authorization dance.
Advanced error handling
Basic rules apply:
- If all goes well, OKAPI will respond with a HTTP 200 status.
- If there is something wrong with your request, you will get a HTTP 4xx
response (with a JSON object described below). These kind of responses should
trigger some kind of an exception inside your application.
- If something goes wrong on our part, you will get a HTTP 5xx response.
We will try to fix such errors as soon as possible.
Each HTTP 4xx error will be properly described in the response, using a JSON error
response. You may retrieve the body of such response and use it inside your application
(for example, to construct various exception subclasses). In most of the cases, only OAuth applications
need to do this. All other applications are fine with threating all HTTP 4xx errors the same.
The error response is a dictionary with a single error key. Its value contains
at least the following keys:
- developer_message - description of the error,
- reason_stack - list of keywords (see below for valid values) which may be
use to subclass exceptions,
- status - HTTP status code (the same which you'll get in response headers),
- more_info - url pointing to a more detailed description of the error
(or, more probably, to the page you're now reading).
Depending on the values on the reason_stack, the error dictionary may
contain additional keys. Possible values of the reason_stack include:
-
["bad_request"] - you've made a bad request.
Subclasses:
-
[ ... , "missing_parameter"] - you didn't supply a required
parameter. Extra keys:
- parameter - the name of the missing parameter.
-
[ ... , "invalid_parameter"] - one of your parameters
has invalid value. Extra keys:
- parameter - the name of the parameter,
- whats_wrong_about_it - description of what was wrong about it.
-
["invalid_oauth_request"] - you've tried to use OAuth, but your request
was invalid.
Subclasses:
-
[ ... , "unsupported_oauth_version"] - you tried
to use unsupported OAuth version (OKAPI requires OAuth 1.0a).
-
[ ... , "missing_parameter"] - you didn't supply
a required parameter. Extra keys:
- parameter - the name of the missing parameter.
-
[ ... , "unsupported_signature_method"] - you
tried to use an unsupported OAuth signature method (OKAPI requires
HMAC-SHA1).
-
[ ... , "invalid_consumer"] - your consumer
does not exist.
-
[ ... , "invalid_token"] - your token
does not exist. This is pretty common, it may have expired (in case
of request tokens) or may have been revoked (in case of access tokens).
You should ask your user to redo the authorization dance.
-
[ ... , "invalid_signature"] - your request
signature was invalid.
-
[ ... , "invalid_timestamp"] - you used a timestamp
which was too far off, compared to the current server time. This is
pretty common, especially when your app is for mobile phones. You should
ask your user to fix the clock or use the provided extra keys to adjust
it yourself. Extra keys:
- yours - timestamp you have supplied,
- ours - timestamp on our server,
- difference - the difference (to be added to your clock),
- threshold - the maximum allowed difference.
-
[ ... , "nonce_already_used"] - most probably,
you have supplied the same request twice (user double-clicked something?).
Or, you have some error in the nonce generator in your OAuth client.
Almost always, you should be fine with catching just three of those:
- ["invalid_oauth_request", "invalid_token"] (reauthorize),
- ["invalid_oauth_request", "invalid_timestamp"] (adjust the timestamp),
- and "any other 4xx status exception" (send yourself a bug report).
How can I participate in OKAPI development?
OKAPI is Open Source and everyone is welcome to participate in the development.
In fact, if you'd like a particular method to exist, we encourage you to
submit your patches.
We have our Issue tracker.
You can use it to contact us!
You may also contact some of
the developers directly,
if you want.
Visit project homepage for details:
http://code.google.com/p/opencaching-api/
List of available methods
OKAPI web services (methods) currently available on this server:
|