So per the discussion on dependsOn(https://github.com/OAI/sig-workflows/issues/153) and the potential notion of a workflow scoped dependsOn, it got me thinking. In the case of most APIs, they often need authorization of some form. Because this is such a common thing for most APIs, it seems a bit redundant that even if we remove step dependsOn and have workflows dependsOn, that every single step will need to set the Authorization header. For example: (https://github.com/OAI/sig-workflows/blob/main/examples/1.0.0/LoginAndRetrievePets.workflow.yaml). The first step is the auth step. The second pulls the auth response token and sets it in a header (Authorization). For a workflow with 50 steps, this is duplicated in every step.
In OpenAPI spec, you can define a set of query options before the methods:
paths:
/: # Root path
parameters:
- $ref: '#/components/parameters/filter' # Common filter parameter
- $ref: '#/components/parameters/page' # Common pagination parameter
get:
summary: List resources
description: Retrieve a list of available resources.
responses:
'200':
description: Successful resource retrieval
In the smidge of a snippet, the root path defines the two query params, that are then automatically assumed as part of every operation including child path operations. There is no need to repeat the declarations for each operation.
Thus, I think something similar should be allowed so that various workflow steps don't have to keep duplicating the same headers, etc. Naturally they CAN do so, but if workflow scoped parameters are provided, they should be automatically part of every step. I would add though that there should be a way to "remove" them per step if desired. For example, a workflow with steps that cross different API surfaces, where a step may hit a public API that doesn't need an Authorization header (and having one could affect the request for some reason lets say).. that step should be able to "block" or "remove" those workflow scoped parameters so that tooling can properly NOT generate code/docs/etc for those.
This may tie in to what Roman was partly discussing in (https://github.com/OAI/sig-workflows/pull/155) though I am not sure how that became a pull request instead of an issue that we discuss? Maybe there was a discussion on this I missed?
So per the discussion on dependsOn(https://github.com/OAI/sig-workflows/issues/153) and the potential notion of a workflow scoped dependsOn, it got me thinking. In the case of most APIs, they often need authorization of some form. Because this is such a common thing for most APIs, it seems a bit redundant that even if we remove step dependsOn and have workflows dependsOn, that every single step will need to set the Authorization header. For example: (https://github.com/OAI/sig-workflows/blob/main/examples/1.0.0/LoginAndRetrievePets.workflow.yaml). The first step is the auth step. The second pulls the auth response token and sets it in a header (Authorization). For a workflow with 50 steps, this is duplicated in every step.
In OpenAPI spec, you can define a set of query options before the methods:
In the smidge of a snippet, the root path defines the two query params, that are then automatically assumed as part of every operation including child path operations. There is no need to repeat the declarations for each operation.
Thus, I think something similar should be allowed so that various workflow steps don't have to keep duplicating the same headers, etc. Naturally they CAN do so, but if workflow scoped parameters are provided, they should be automatically part of every step. I would add though that there should be a way to "remove" them per step if desired. For example, a workflow with steps that cross different API surfaces, where a step may hit a public API that doesn't need an Authorization header (and having one could affect the request for some reason lets say).. that step should be able to "block" or "remove" those workflow scoped parameters so that tooling can properly NOT generate code/docs/etc for those.
This may tie in to what Roman was partly discussing in (https://github.com/OAI/sig-workflows/pull/155) though I am not sure how that became a pull request instead of an issue that we discuss? Maybe there was a discussion on this I missed?