Provide a CLI command to get the URL needed to invoke a particular action

[andreasnauerz]

Provide a CLI command to get the URL needed to invoke a particular action.

Example: Command: wsk action create hello --api-url Response: PUT https://irgendwo.auf.bluemix.net/api/v1/namespaces/meineid_dev/actions/hello

[domdom82]

I suggest to conflate this with API keys and rather

wsk api key create <target entity> [rwx rights] [expiry time]

e.g.

wsk api key create mykey /mynamespace/myaction rx 12h
ok: created api key mykey

wsk api key get mykey
{
  name: mykey,
  target: /mynamespace/myaction,
  target_url: https://openwhisk.ng.bluemix.net/api/v1/namespaces/mynamespace/actions/myaction?token=abcdef1234,
  rights: [read,execute],
  expires: (ISO-date + 12 hours)
}

wsk api key get --url mykey
https://openwhisk.ng.bluemix.net/api/v1/namespaces/mynamespace/actions/myaction?token=abcdef1234

Adding this feature without adding API keys first would always give out private information.

[markusthoemmes]

The issue seems to be more around getting to know what exactly to send to our API to get to a specific result? If so, what about wsk -v --dry wsk action create hello? Where --dry just does a dry run and not sending the request.

[andreasnauerz]

I must admit that I am not 100% sure how exactly the feedback has to be interpreted; but let me point Julian who gave this feedback to this issue here to clarify what he was/is looking for ;)

[mbehrendt]

as mentioned in our e-mail exchange, i think it's as simple as 'give me the url i have to send an http msg to for invoking this action'

[andreasnauerz]

Yes, you are probably right, but before I speculate I better ask the one who gave that feedback to clarify - does not cost a lot to ask to be 100% sure we got it the right way.

[julicjung]

Hey there, the idea for the enhancement was actually quite simple: For all commands which can be issued from the wsk CLI tool, provide an option --api-url which outputs the REST URL to run the same command. This is not limited to invoking actions but also creating triggers, enabling/disabling rules etc. I know about the Swaggerfile, but since the wsk tool is so convenient users might find it helpful there too.

How did I come up with this idea? I wanted to know how I could invoke an action or fire a trigger via curl, both for testing/learning purposes as well as later integration with my existing server based code. The last part is especially important to me, as I discovered that all my (personal) applications etc talk HTTP to each another (at least as the default).

Another use case is automatic creation of environments, e.g. I want to provide a Whisk application as a "deployable" package, which could consist of a bunch of .js files and a bash script which creates also entities via curl calls. To find the proper calls I can again either consult the Swaggerfile (if I know where it is burried ;-)) or just give the --api-url flag to the calls I used during development time. An extension from this idea is to also generate payloads from the --param option flags.

For example Cloudant provides similar functionality in their web console; you can always copy an URL from the top right.

Feel free to ask any follow-up questions, I gladly participate.

[mbehrendt]

wouldn't wsk -v <command> address this requirement?

[julicjung]

Just tried it. The info is in there, so this would do. My understanding from trying --dry is that there is no dry run option (yet). Although the output I had in mind would more resemble the one from --summary. I also would not have expected that information behind a -v, purely based on the naming.

[markusthoemmes]

-v, --verbose is used mainly as a debug measure, to really see what your CLI is doing (which is kind of what you want to achieve). A --dry option as suggested above would be convenient in that you wouldn't need to actually create, delete, invoke something to see which commands the CLI outputs.

While we do have a swagger documentation and all that, certain parts of the API are sugared by the CLI, e.g. --feed or --sequence, so there definitively is a benefit in being able to see what the CLI really does.

[julicjung]

And this is why I did not look for -v. So one question would be is this information helpful enough to provide it on its own? Another question which comes to my mind is that based on your comment there is some magic baked into the CLI, say, --sequence, for which it would not be readily obvious how to replicate it via REST calls? In this case an --api-url flag could help understand what actually is going on without the noise of -v? ...just thinking aloud.

[domdom82]

IMHO it should actually be the other way around. I have seen other APIs (read: OpenStack) become actually unusable without the CLI client because there were so many "hidden" fields and features used by the CLI that weren't documented or explained on API level. A REST API should be self-explanatory without the need for a particular client.

Granted, a -v option helps at first sight. For this very issue I would suggest a "--curl" option that spits out complete curl commands for your convenience. You could even combine it with a "--dry" option to only get curls.

[csantanapr]

To move forward with an actionable item, I think this issue should be scoped to the most common need, as the initial input to the issue was about invoking an action, I would say directly (invoking) or indirectly (fire trigger)

I think starting with something simple for invoking and action and firing a trigger and just displaying the curl command. To summarize implement a --curl flag for wsk action invoke and wsk trigger fire This flag will just print the full curl command that user would simple copy paste in to a script or terminal, or inspect to understand the http call for these two specific commands Examples: print curl command to invoke action

$ wsk action invoke /whisk.system/samples/echo -p message hola -b -r --curl
curl -d "${WSK_PARAMS}" -XPOST -H "${WSK_CONTENT_HEADER}" -H "${CURRENT_AUTH_HEADER}" "${WSK_PATH}"

print curl command to fire a trigger

$ wsk trigger fire stockTrigger '{"IBM":200}' --curl
curl -d "${WSK_PARAMS}" -XPOST -H "${WSK_CONTENT_HEADER}" -H "${CURRENT_AUTH_HEADER}" "${WSK_PATH}"

The ${xx} would be substitute with actual values.

For reference: here is a script I usually refer to when I want to use curl https://github.com/csantanapr/openwhisk-demos/blob/master/stocks/wskproject.sh#L83

[mbehrendt]

since the url is some sort of data about an action -- could we make the url part of wsk action get?

if someone wants to see the url for a specific set of parameters, wsk -v action invoke should provide all information.

thoughts?

[csantanapr]

@mbehrendt I don't follow your proposal. I think the initial requirement was to show the user a simple curl command to run an action. I think what I proposed provides this, also it matches what Bluemix provides in their UI were they offer the user an easy copy button for the curl command.

Are you saying that what I proposed is wrong? We should not provide the curl command?

Today we don't have in the go-cli a get for specific property of the action, url is something that can be compose at the CLI side, since it's not stored in the action document int he DB, This other issue is tracking the work for wsk action get ACTION_NAME [PROPERTY_NAME] #986 you can request that url is valid PROPERTY_NAME to support.

[rabbah]

The url has these parts:

1. Basic auth
2. Deployment host
3. API version
4. Resource name

Only the last of these is part of the action the rest are not intrinsic properties.

Also while we currently have only way to refer to the resource with different http verbs to operate on it, there is an issue now open that discusses having different ways of invoking an action viz. a get which requires a different url and may work in the future with an url snipper; in which case the relevant information to reconstruct the corresponding url would become part of the action (e.g., the snipped hash).

[rabbah]

The --url which was recently added allows one to get the URL for an action invoke (for POST and webaction).

For the API gw URLs, I think this is not supported but that seems like it should be part of the API gw submenu and hence I'm inclined to close this issue which is more generally for actions. I'd expect the API gw to separately address this.

@mdeuser @csantanapr thoughts? Shall I close this issue?

[mdeuser]

urls generated by the api gw when creating an api are available via wsk api list FILTERS or wsk api list FILTERS --full. the former provides the api details in a single row; the latter breaks out the api details into multiple rows - with the url being on a separate line.

so, i believe the desired api url information is provided. if this was the last sticking point and baring no other objections, i agree that this issue can be closed.