...
There will be a set of marketplace APIs that the UI will use to get categories and packages. In the first version of the market, the APIs will simply be static content served from S3. This essentially amounts to placing packages in a pre-determined directory structure, and generating index files that will be used to get metadata about the packages, such as the list of all packages, list of packages in a category, versions of a package, etc.
There will be an internal process to push the entire market repository to S3. If a user wishes to host their own marketplace, they can do so using their own S3 instance or by hosting their own server.
APIs
The APIs are simply a contract about the directory structure of the marketplace. All APIs are relative to a base path. For example, cask.co/marketplace/v1.
...
. The structure is expected to be:
| Code Block |
|---|
<base>/categories.json
<base>/packages.json
<base>/packages-<category>.json
<base>/packages/<package-name>/versions.json
<base>/packages/<package-name>/<version>/icon.jpg
<base>/packages/<package-name>/<version>/spec.json
<base>/packages/<package-name>/<version>/spec.json.asc
<base>/packages/<package-name>/<version>/archive.zip
<base>/packages/<package-name>/<version>/archive.zip.asc |
| Note |
|---|
In order to make serving easier, we are sacrificing flexibility and extensibility. For example, searching and filtering packages (beyond filtering by a single category) cannot be done in this way. One useful thing we may want to support very soon is filtering packages based on the CDAP version. |
List Categories
| Code Block |
|---|
GET /categories.json
[
{
"name": "examples",
"label": "Examples",
"description": "Example applications to get started with CDAP."
},
{
"name": "use-cases",
"label": "Use Cases",
"description": "Common Use Cases."
},
...
] |
...
Get Package Spec
| Code Block |
|---|
GET /packages/<package><package-name>/<version>/spec.json ex: GET /packages/PurchaseExample/4.0.1/spec.json { "spec-version": "1.0", "name": "PurchaseExample", "label": "Purchase History", "description": "Example Application demonstrating usage of flows, workflows, mapreduce, and services.", "author": "Cask", "org": "Cask Data Inc.", "version": "4.0.1", "created": 1234567899, "changelog": "fixed a small parsing bug", "categories": [ "examples" ], "dependencies": { "cdap": { "minVersion": "4.0.0", "maxVersion": "4.1.0" } }, "actions": [ { "type": "create_artifact", "arguments": [ { "name": "name", "value": "PurchaseHistoryExample" }, { "name": "version", "value": "4.0.1" }, { "name": "scope", "value": "user" }, { "name": "jar", "value": "PurchaseHistoryExample-4.0.1.jar" } ] }, { "type": "create_app", "arguments": [ { "name": "name", "default": "PurchaseHistory" } ] } ] } |
Get Package Spec Signature
| Code Block |
|---|
GET /packages/<package><package-name>/<version>/spec.asc ex: GET /packages/PurchaseExample/4.0.1/spec.asc [ spec signature ] |
Get Package Icon
| Code Block |
|---|
GET /packages/<package-name>/<version>/icon.jpg |
Security
Since people will be able to download code from the marketplace, it is especially important that there is protection against malicious code. We can make use of PGP in order to sign both the package archive and the package spec that are downloadable from the marketplace. The Market UI will have to be configured to use a GPG key (for the public CDAP marketplace, we could re-use the GPG key used for CDAP rpms and debians or create another one). It can then use that public key along with the signature APIs to verify that the spec and archive were signed by the owner of the package.
...