API Gateway - Support "application/x-www-form-urlencoded" content type

[jthomas]

Steps to reproduce the issue:

I'm attempting to use Slack's Outgoing Webhooks with OpenWhisk Actions using the API Gateway. Slack sends the following requests when the webhook is invoked. https://requestb.in/13tqn671?inspect

It's a "application/x-www-form-urlencoded" content type. It would be useful to unwrap the form parameters and invoke the Action.

[csantanapr]

It's not an issue, it's a known limitation and we are aware of it. Currently application/json in application/json out. And were trying our best to get an MVP out and this didn't make the cut, until gateway service supports this type of things.

This makes me think we should add link per bullet in the apigateway docs for the feedback and limitations that we are already aware and evaluating.

Only Content Type application/json is supported for request and response.

Ref:

Note: This feature is currently an experimental offering that enables users an early opportunity to try it out and provide feedback. The following feedback has already been received:
No ability to control HTTP access control for Cross-Origin Resource Sharing (CORS).
**Only Content Type application/json is supported for request and response.**
No programatic way to control the response from the OpenWhisk action.
All OpenWhisk actions are expose via public access, no ability to configure a custom API key.
Path parameters are not supported, only query parameter and request body.
If the API is created without an API name, the name will be the base path and this cannot be changed
When re-creating APIs via input file, the API needs to be deleted first.
When exporting APIs this contain your OpenWhisk API key, this information is sensitive, no templating available.

[jthomas]

Agreed it's not an "issue". It's a "feature request". Do you want to collect these here or somewhere else?

[csantanapr]

I want to collect them in Github. Hum not sure how best to track.

What you think if we have a TopLevel Github Issues to track all as a bullet feedback, and then a individual issue per each and a link to it. when there is new feedack we can edit the toplevel comment on the toplevel github issue.

[jthomas]

I've seen other projects use a label (feature-request) and a label for the project component (api-gateway) to track these things. That might be easier to maintain the having to manually update a top-level ticket?

[csantanapr]

ha better idea we already have a apigw label and feedback label we can use both.

Can you help create those issues for the list that we currently have in the docs?

[csantanapr]

In the issue you can give it a more user point of view of what would be the use case that feature request would support if implemented.

[jthomas]

@csantanapr will do, do you want to label this issue? :)

[rabbah]

Is this a duplicate of https://github.com/openwhisk/openwhisk/issues/567?

In the meta-API extensions that we recently added, we applied a precedence order: package parameters -> action parameters -> query parameters -> post parameters (last wins). We can adopt the same precedence order and it would make supporting this feature not particularly time consuming.

[aarora91]

@jthomas thanks for pointing me here. I am able to curl to my API gateway endpoint without providing any auth! :) However, doesn't work when I try integrating with Slack's outgoing webhook. I'm guessing it's the same problem you faced with the content type. Do you know if there's a fix for this yet?

[csantanapr]

This is now resolved by using Web Actions https://github.com/openwhisk/openwhisk/pull/2010