Action Execution#1
Conversation
|
|
||
| ##### Action <a name="action"></a> ##### | ||
|
|
||
| | Response field | Type | Description | |
There was a problem hiding this comment.
Instead of coming up with our own definition for describing APIs, I'd like to understand why .../actions can't just return a swagger spec. Seems like at the very least we should figure out why it is not sufficient for our needs.
https://github.com/OAI/OpenAPI-Specification
There was a problem hiding this comment.
I'm not sure I understand the comment. /actions returns the list of actions that can be performed on a service instance and not the list of API's that exist.
There was a problem hiding this comment.
Right, so the question you're asking from the endpoint is what actions can be performed. I presume each action that you call is an HTTP request and if so, then you're describing an API? Inputs/outputs, etc. and it seems like if you call the /actions, returning a swagger document which is an open spec for describing APIs rather than defining our own format would seem better unless there's a strong reason not to do that?
There was a problem hiding this comment.
Each action execution (see line 887 onwards) is a POST /v2/service_instances/:instance_id/actions/:action_id/executions/:execution_id with action id and parameters. So any action is just a call to a single API to execute that action.
What you are referring to is a way to discover the actions that a service brker supports for a service instance. The actions once discovered can be executed using the API mentioned above. I believe what I have here is very similar to the proposals here cloudfoundry#114 from gberche-orange . I think the big difference is breaking up the relationship of the actions from plans and allowing a broker to dynamically publish the actions it supports for a service instance.
There was a problem hiding this comment.
@vaikas-google The /actions get gives you a lot of information about the tasks that you can use to render to the user.
As I mentioned earlier, these are broker defined actions .i.e. what the task is, what it does is completely controlled by the broker and a broker could introduce any type of action. The platform shouldnt have to care what the action actually does, but just that there are a set of actions available and each action might require user input. The data returned by the /actions allows the platform to present the list of actions available to the end user in the context of a service instance and if the user selects a particular action, present the user with a UI to collect the required parameters and finally submit the action for execution.
|
Yeah, so the one thing I've been thinking about is if it's enough to assume
that brokers perform all the actions. My understanding is that there are
plenty of actions that are already implemented by the dashboard URL
endpoint provided by many of the service providers. Forcing the endpoint to
be tied to /actions is a choice that forces the broker to possibly proxy
all these requests. Note that by not tying the actions to /actions does not
prevent the broker exposing these as /actions but would allow for a more
generic endpoint API discovery mechanism.
…On Thu, May 25, 2017 at 8:15 AM, rohitkshetty ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In spec.md
<#1 (comment)>
:
> +The `:instance_id` of a service instance that has been provisioned previously.
+
+#### cURL ####
+<pre class="terminal">
+ $ curl -H "X-Broker-API-Version: 2.11" ***@***.***/v2/service_instances/:instance_id/actions
+</pre>
+
+### Response ###
+
+| Status Code | Description |
+|---|---|
+| 200 OK | The expected response body is below. |
+
+##### Action <a name="action"></a> #####
+
+| Response field | Type | Description |
@vaikas-google <https://github.com/vaikas-google> The /actions get gives
you a lot of information about the tasks that you can use to render to the
user.
As I mentioned earlier, these are broker defined actions .i.e. what the
task is, what it does is completely controlled by the broker and a broker
could introduce any type of action. The platform shouldnt have to care what
the action actually does, but just that there are a set of actions
available and each action might require user input. The data returned by
the /actions allows the platform to present the list of actions available
to the end user in the context of a service instance and if the user
selects a particular action, present the user with a UI to collect the
required parameters and finally submit the action for execution.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKwedFNXaH4Se4JSxT6W70pFKweJJ-6dks5r9Zr3gaJpZM4NaQlt>
.
|
|
Please see: cloudfoundry#431 |
3 participants
No description provided.