Using aptly via REST API allows to achieve two goals:
Run aptly api serve to start HTTP service:
$ aptly api serve
Starting web server at: :8080 (press Ctrl+C to quit)...
[GIN-debug] GET /api/version --> github.com/aptly-dev/aptly/api.apiVersion (4 handlers)
...
By default aptly would listen on :8080, but it could be changed with -listen flag.
Usage:
$ aptly api serve -listen=:8080
Flags:
-listen=":8080": host:port for HTTP listening-no-lock: don’t lock the databaseWhen -no-lock option is enabled, API server acquires and drops the lock
around all the operations, so that API and CLI could be used concurrently.
Try some APIs:
$ curl http://localhost:8080/api/version
{"Version":"0.9~dev"}
$ curl -F file=@aptly_0.8_i386.deb http://localhost:8080/api/files/aptly_0.8
["aptly_0.8/aptly_0.8_i386.deb"]
$ curl -X POST -H 'Content-Type: application/json' --data '{"Name": "aptly-repo"}' http://localhost:8080/api/repos
{"Name":"aptly-repo","Comment":"","DefaultDistribution":"","DefaultComponent":""}
$ curl -X POST http://localhost:8080/api/repos/aptly-repo/file/aptly_0.8
{"failedFiles":[],"report":{"warnings":[],"added":["aptly_0.8_i386 added"],"removed":[]}}
$ curl http://localhost:8080/api/repos/aptly-repo/packages
["Pi386 aptly 0.8 966561016b44ed80"]
$ curl -X POST -H 'Content-Type: application/json' --data '{"Distribution": "wheezy", "Sources": [{"Name": "aptly-repo"}]}' http://localhost:8080/api/publish//repos
{"Architectures":["i386"],"Distribution":"wheezy","Label":"","Origin":"","Prefix":".","SourceKind":"local","Sources":[{"Component":"main","Name":"aptly-repo"}],"Storage":""}
For security reasons it is advised to let Aptly listen on a Unix domain socket
rather than a port. Sockets are subject to file permissions and thus allow for
user-level access control while binding to a port only gives host-level access
control. To use a socket simply run Aptly with a suitable listen flag such as
aptly api serve -listen=unix:///var/run/aptly.sock.
Aptly’s HTTP API shouldn’t be directly exposed to the Internet: there’s no authentication/protection of APIs. To publish the API it could be proxied through a HTTP proxy or server (e.g. nginx) to add an authentication mechanism or disallow all non-GET requests. Reference example for LDAP based per-repo access with nginx.
/ in them.aptly mirror: mirror APIlist: listcreate: createdrop: deleteshow: showsearch: show packages/searchupdate: update mirroraptly repo: local repos APIadd: file upload API + add packages from uploaded filecopy: show packages/search + add packages by keycreate: createdrop: deleteedit: editimport: not available, as mirror API is not implemented yetlist: listmove: show packages/search + add packages by key + delete packages by keyremove: show packages/search + delete packages by keyrename: not available yet, should be part of edit APIsearch: show packages/searchshow: showaptly snapshot: snapshots APIcreate:diff: snapshot difference APIdrop: deletefilter: show packages/search + create snapshot from package referenceslist: listmerge: show packages/search + processing + create snapshot from package referencespull: show packages/search + processing + create snapshot from package references (might be implemented as API in future versions)rename: editsearch: show packages/searchshow: showverify: not available yetaptly publish: publish APIdrop: deletelist: listrepo: publish reposnapshot: publish snapshotswitch: switch/updateupdate: switch/updateaptly package: packages APIsearch: not available yetshow: only one format, with package key as inputaptly graph: graph APIaptly version: version APIaptly db: not available yet