You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What stacktrace or error message from your provider did you see?
For feature proposals:
User creates a Serverless service, containing n functions. User deploys the service, AWS allocates a randonly named API gateway URL for the service, suffixed with each function. User wants to open one or more functions in a browser.
Might be sensible to enable 'open all functions in browser' or 'open this function in browser' by default?
Similar or dependent issue(s):
none
Additional Data
Extension version:
Serverless Framework:
Version:
Serverless installed globally
Operating System:
Stack Trace (if available):
The text was updated successfully, but these errors were encountered:
You're absolutely right. The feature makes sense because of the random nature of the API and lambda path names. Of course the AWS specific functions should only appear if used with an AWS service (the plugin should be compatible with all others too, like Azure, OpenWhisk, Google, etc.).
However, there are some things that need to be clarified first. If we offer a context menu entry "open in browser" on a http endpoint in the serverless tree, wouldn't that only be suitable for GET requests?
How could such a feature be offered for other endpoint types like PUT or POST?
On a function level (the function nodes in the tree) it would not make so much sense, because the lambda's url itself is only a POST capable url. There it might be better to offer something like "open in AWS console".
I take your point about POST (or other) http methods, the suggestion is only really good for a GET request.
Another option (perhaps more valid for POST etc) might be to generate a Postman (or other REST client) collection which targets the URLs exposed by the service?
might be to generate a Postman (or other REST client) collection
I like the idea. A PostMan collection would be great and I'd even favor that for all endpoints. The REST client type could then be defined in the configuration (with a default of PostMan), so that other clients could be added as well (as soon as someone has a specific demand).
Additionally this fits into a good OOD approach for the extension's implementation itself.
This is a (Feature Proposal)
Description
For bug reports:
For feature proposals:
Similar or dependent issue(s):
Additional Data
Version:
The text was updated successfully, but these errors were encountered: