Open theophoric opened 8 years ago
As a corollary to this creating an action in the context of a package could be done through [POST] /namespaces/{namespaceName}/packages/{packageName}/actions
Actions that are not in an explicitly named package are considered part of the default
package. In this way, we can consider unifying the packages and actions API endpoints in this way /namespaces/{namespaceName}/packages/{packageName}/actions/{actionName}
and reserve the package name default
. In fact, we can take this further and eschew the packages endpoints all together, unifying the entity types in the same way.
I'm in favor of this proposal since it follows the hierarchical nature of namespaces, packages and actions.
I think this will be addressed in the v2 API changes.
With the roll out of a stricter 1-1 mapping from key to namespace, an alternate way to evolve the API is to drop the namespace
entirely from the URI (since the value will always be unambiguous and the _
place holder becomes canonical).
So rather than always specifying resources with /namespaces/_/{actions, triggers, rules, activations, packages}/name
it becomes more convenient, elegant and uniform to drop the /namespaces/_
segment and treat the entire path following one of the collection qualifiers as the fully qualified name (where one segment implies resource in default namespace and package, two segments implies resource in default namespace with named package and entity) and three segments implies a fully qualified name with namespace, package and entity names.
This makes it potentially nicer to also filter activations in a namespace, package or by action:
/activations/
lists all activation in the namespace, /activations/package-name
for activations filtered by package, and /activations/package-name/entity-name
for activations of an entity in a package. And of course /activations/namespace-name/package-name
and /activations/namespace-name/package-name/action-name
for activation in some other namespace and package assuming entitled subject.
(Alternatively, activations could be come their own resources under the actions collection actions/action-name/activations
e.g.)
Related to #1635.
While we can do this as part of v2 API, it's also possible to do as part of the current version with some nginx rewriting. Below I listed what the new API paths would look like for our current core API.
show below for actions but intended to be the same for triggers and rules:
get /api/v2/actions/ns/pkg/action
put /api/v2/actions/ns/pkg/action
del /api/v2/actions/ns/pkg/action
post /api/v2/actions/ns/pkg/action
get /api/v2/actions/ns/pkg
get /api/v2/actions/ns
?override
, ?createonly
, ?updateonly
for putget /api/v2/packages/ns/pkg
(default not allowed)put /api/v2/actions/ns/pkg
(default not allowed, cannot be bound)/api/v2/actions/ns/pkg
(default not allowed)fet /api/v2/actions/ns
/api/v2/activations/?id=
/api/v2/activations/?name=
get /api/v2/activations/ns/pkg/action
get /api/v2/activations/ns/pkg
get /api/v2/activations/ns
show below for actions but intended to be the same for triggers and rules:
Would this also include compositions like sequences?
Would this also include compositions like sequences?
a sequence is an action - so yes.
ack. so the the "keyword" to address compositions would be "action" as well? e.g.
put /api/v2/actions/ns/pkg/action
would also be used to a composition/sequence?
That's correct - this is an important property for actions in openwhisk (a composition produces an action).
@rabbah, namespace or no namespace in API V2?
do you mean should we continue to allow "_" for convenience? I don't see how we can eliminate namespace (in case one is referring to a public package for example).
Currently the route to retrieve a list of actions associated with a given namespace and package is
/namespaces/{namespaceName}/actions/{packageName}/
. This is confusingly similar to the route for retrieving an action/namespaces/{namespaceName}/actions/{actionName}
. I propose that the route for getting a list of actions associated with a package be changed to/namespaces/{namespaceName}/packages/{packageName}/actions
to avoid this confusion and adhere more strictly to restful principles.