|
1
|
1 |
|
|
|
2 |
pkg
|
|
|
3 |
Use of REST
|
|
|
4 |
|
|
|
5 |
We use REST over HTTP as the primary networking API between client and
|
|
|
6 |
server. That choice means that
|
|
|
7 |
|
|
|
8 |
- the client can be reimplemented,
|
|
|
9 |
|
|
|
10 |
- the server can be reimplemented, and
|
|
|
11 |
|
|
|
12 |
- decorations on a transaction, like authentication, encryption, and
|
|
|
13 |
redirection, can be handled using the enormous technology set around
|
|
|
14 |
HTTP.
|
|
|
15 |
|
|
|
16 |
The first two are true of any well-defined protocol, but we benefit in
|
|
|
17 |
this case from the wide availability of HTTP client and server
|
|
|
18 |
implementation starting points.
|
|
|
19 |
|
|
|
20 |
Installer API:
|
|
|
21 |
|
|
|
22 |
GET /catalog
|
|
|
23 |
GET /version/pkg_name
|
|
|
24 |
GET /depend/pkg_name
|
|
|
25 |
GET /data/pkg_name[/from[/to]]
|
|
|
26 |
|
|
|
27 |
Packager API:
|
|
|
28 |
|
|
|
29 |
POST /trans/pkg_name
|
|
|
30 |
Returning a transaction ID
|
|
|
31 |
POST /add/trans_id/type
|
|
|
32 |
Plus metadata in submitted headers and contents as file body.
|
|
|
33 |
GET /summary/trans_id
|
|
|
34 |
POST /meta/trans_id/require
|
|
|
35 |
Dependency metadata in submitted headers.
|
|
|
36 |
POST /commit/trans_id
|
|
|
37 |
Returning package URL.
|
|
|
38 |
|