Project

General

Profile

Hacking SDKs » History » Version 1

Tom Clegg, 05/16/2014 10:17 PM

1 1 Tom Clegg
h1. Hacking SDKs
2
3
{{toc}}
4
5
h2. Basics
6
7
APIs use REST over HTTP and websockets.
8
9
We try to be (mostly) compatible with Google APIs. If there is a Google API client library (or library generator) for your language of choice, that is probably a good place to start.
10
11
Discovery document
12
* The discovery document is generated by the API server at runtime, and tells you what the API methods and schemas are.
13
* In a language like Java or Go, you use the discovery doc to generate a client library.
14
* In a language like Ruby and Python, you can load the discovery doc at runtime.
15
16
h2. Gotchas
17
18
h3. SSL certificates
19
20
Stock Google SDKs (and HTTP libraries) make it difficult to disable SSL certificate/CA verification. This can make development and testing awkward. This is generally the first hurdle. You could get unstuck by adding your test/dev server's SSL certificate to the relevant HTTP library's "trusted certificate" store, but (so far) there's always been a way to disable verification at runtime as indicated by the ARVADOS_API_HOST_INSECURE setting.
21
22
h3. Authorization
23
24
No need to think too hard about OAuth2 at this point. Just put ARVADOS_API_TOKEN in the Authorization header of each request, like this:
25
26
<pre>
27
Authorization: OAuth2 abcd1234apitokengoeshere1234abcd
28
</pre>
29
30
h3. Request body
31
32
Where [most] Google APIs put a single JSON-encoded object in the *request body*, we accept a JSON document with zero or more objects. For example, instead of this:
33
34
<pre>
35
{"link_class":"test"}
36
</pre>
37
38
we do this:
39
40
<pre>
41
{"link":{"link_class":"test"}}
42
</pre>
43
44
This is expressed in the discovery document, but stock Google SDKs don't tend to understand it.