TaskService get operation responses missing
Closed this issue · 2 comments
/redfish/v1/TaskService/Tasks/{TaskId}:
get:
parameters:
- description: The value of the Id property of the Task resource
in: path
name: TaskId
required: true
schema:
type: string
responses:
'200':
content:
application/json:
schema:
$ref: http://redfish.dmtf.org/schemas/v1/Task.v1_7_3.yaml#/components/schemas/Task_v1_7_3_Task
description: The response contains a representation of the Task resource
default:
content:
application/json:
schema:
$ref: '#/components/schemas/RedfishError'
description: Error conditionDSP 0266 - 7.5 Data modification requests states
- the created resource may be returned in response to a request to the task monitor URI with the HTTP 201 Created status code.
- the modified resource may be returned in response to a request to the task monitor URI with the HTTP 200 OK status code.
this resource does not have to match Task JSON structure.
The get operation of the task service does not define a response 201 and misses a content type "/" for status_code 200.
DSP 0266 - 12.2 Asynchronous operations mentions
- … a client issues a request that results in a long-running operation, the service returns the HTTP 202 Accepted status code …
The operation for the task monitor misses a response definition for status_code 202.
Invoking an operation on /redfish/v1/TaskService/Tasks/{TaskId} is not the same as the task monitor. That specific URI is meant for an administrator to see all tasks (complete, pending, in progress, etc), and perform DELETE operations on them. It's not expected for a service to return anything other than 200 on those URI patterns for GET operations.
The task monitor URIs are intended to be opaque URIs, much like how the "BinaryDataUri" property in Assembly points to a URI outside of the model definitions. For task monitors, the spec gives guidance to use the pattern "/redfish/v1/TaskService/TaskMonitors/{TaskId}" for these special URIs.