Rodric this is a great idea to support it as part of `/v1`.
A quick comment on:
* get by id /api/v2/activations/?id=
Is this a search or a get, in which case we could maybe use:
GET /api/v2/activations/{id}
also what about providing a vanity URL to the latest activation of an
action ?
GET /api/v2/activations/ns/pkg/action/latest
or
GET /api/v2/actions/ns/pkg/action/activations/latest
dragos
From: Rodric Rabbah
Sent: Monday, January 16, 2017 12:15:57 PM
To: d...@openwhisk.incubator.apache.org
Subject: simplifying the URLs for API calls
With the recent changes we've made to OpenWhisk to make the mapping of keys
to namespace strictly 1-1, we can simplify the URLs for API calls (some
users have already picked up on this). I'm added a comment to an
outstanding issue about this potential improvement we can make [1] where
initially the thought was to do this as part of a v2 of the API but I think
it's entirely possible to support the cleaner URLs as part of v1 with some
nginx rewrites as well. Regardless, we should leverage the stricter mapping
and simplify the URLs because they'll be less confusing.
I'm pasting my comment below as well for your convenience.
[1] https://github.com/openwhisk/openwhisk/issues/219#issuecomment-272951007
- *Let* ns = namespace name or “_”
- *Let* pkg = package name or “default”
- *Let* action = action name
basic CRUD + activate operations for actions, triggers, rules
show below for actions but intended to be the same for triggers and rules:
read get /api/v2/actions/ns/pkg/action create/update put
/api/v2/actions/ns/pkg/action delete del /api/v2/actions/ns/pkg/action activate
post /api/v2/actions/ns/pkg/action list all actions in package get
/api/v2/actions/ns/pkg list all actions in all packages in namespace get
/api/v2/actions/ns questions and considerations
- get/put/del only the exec part of the schema e.g., "code" or "zip"?
- want streaming for the “code” or “zip”, treat as attachments, treat as
subresource?
- support ?override, ?createonly, ?updateonly for put
- list all actions in package can include bindings
- list all actions in all packages cannot easily includes bindings
(couchdb reasons)
- allow for action extensions for content type and projection for result
path as in "web" feature?
basic CRUD operations for packages get package or binding get
/api/v2/packages/ns/pkg (default not allowed) create/update package or
binding put /api/v2/actions/ns/pkg (default not allowed, cannot be
bound) delete
package or binding /api/v2/actions/ns/pkg (default not allowed) list all
packages and bindings in namespace fet /api/v2/actions/ns basic read
operations for activations get by id /api/v2/activations/?id= get by name
/api/v2/activations/?name= get all activations for action get
/api/v2/activations/ns/pkg/action list all activations for actions in
package get /api/v2/activations/ns/pkg list all activations in all packages
in namespace get /api/v2/activations/ns questions and considerations
- get only logs, as subresource?
- get only results, as subresource?
- want streaming for the “logs” and the “results”, treat as attachments
also
- support start, end, skip, limit on all list operations, return totals
to allow pagination
- listing activations for packages may not include bindings
