fish
Guppy
Posts: 65
|
Post by fish on Feb 1, 2018 15:17:48 GMT
Hi,
A Redfish service needs to respond with some temporary string data in the HTTP response body of an OEM action. This string data is not naturally a property of any resource. But I conclude from the specification (1.4) in chapter 6.4.4.7 “Actions (POST)” that response body of Action (POST) must only include data in the form of a message /error-message. And I want the action the be Redfish compliant still. Does this mean I need to find some work-around like exposing this data as some kind of temporarily available resource property, or exposing some property with an URI for downloading this string data as a separate file (“outside” Redfish API), after the action has been invoked?
Related observation: same chapter 6.4.4.7 “Actions (POST)” says: “In cases where the processing of the Action may require extra time to get completed, the service may respond with an HTTP Status code of 202 with a location header in the response set to the URI of a Task resource.”
I guess this is wrong? Should be “Task monitor” and not “task resource”? According to chapter “8.2. Asynchronous operations”: “Any response with a status code of 202 (Accepted) shall include a location header containing the URL of the Task Monitor and …”
|
|
|
|
Post by jautor on Feb 2, 2018 18:48:29 GMT
Related observation: same chapter 6.4.4.7 “Actions (POST)” says: “In cases where the processing of the Action may require extra time to get completed, the service may respond with an HTTP Status code of 202 with a location header in the response set to the URI of a Task resource.”
I guess this is wrong? Should be “Task monitor” and not “task resource”? According to chapter “8.2. Asynchronous operations”: “Any response with a status code of 202 (Accepted) shall include a location header containing the URL of the Task Monitor and …”
You are correct, that is an errata in a number of instances in that section, and needs to be corrected. We will fix that in the next release of the Specification. Thanks for finding and reporting that! Jeff |
|
|
|
Post by jautor on Feb 2, 2018 18:53:28 GMT
Hi,
A Redfish service needs to respond with some temporary string data in the HTTP response body of an OEM action. This string data is not naturally a property of any resource. But I conclude from the specification (1.4) in chapter 6.4.4.7 “Actions (POST)” that response body of Action (POST) must only include data in the form of a message /error-message. And I want the action the be Redfish compliant still. Does this mean I need to find some work-around like exposing this data as some kind of temporarily available resource property, or exposing some property with an URI for downloading this string data as a separate file (“outside” Redfish API), after the action has been invoked?
Is there really no data in the resource that relates to the Action? Is that string data something that would be appropriate for a "Message" response? But this topic has come up once before, and I'll bring it up again to see if this is something that the Forum sees as something to address in the specification. If you can provide any examples (even hypothetical) of cases where this pattern would get used, that would be helpful to make the case. Thanks, Jeff |
|
fish
Guppy
Posts: 65
|
Post by fish on Oct 10, 2019 9:02:02 GMT
Hi again,
How to handle action response body for new OEM actions (and Redfish actions) is unfortunately still an issue I think. I was looking at Specification 1.8.0 chapter 7.10 to see if there was any updates, but the rules seems still to be that response body shall be empty or contain a Message that indicates either error or success. OK?
But now I happened to look at some actions defined in Credential Schema (Rekey and Renew actions). These are defined in CSDL using "ReturnType" (and "actionResponse" in JSON schema), which seems to be used for defining parameters of an action response body. And these action response bodies seems to not consist of Message only...? (Same construct seems to be used also for actions response body in schema for CertificateService, and maybe more places?)
So it almost seems that these new credential actions are not aligned to the Redfish specification of actions? Or is this some new action handling that was by mistake not yet added to the specification? Or am I misunderstanding this completely, or reading in the wrong place in the Specification...? Because this kind of mechanism for responding with some parameters (that are not only a Message) was what I was looking for before when I started this thread.
Other related question: If now some actions may respond with "non-Message" body, can they still respond with Message in body in case of error? Should this be reflected in the schema of the response body in such case, so that "Message type" is alternative response type of the action? (It does not look like this in the Certificate actions I think?)
BR
/Magnus
|
|
|
|
Post by mraineri on Oct 11, 2019 16:45:14 GMT
You're correct; this is definitely a gap in the spec at the moment. Actions should default to returning that "error" payload with messages (even in success cases), unless otherwise specified with a dedicated return type specified by the schema.
|
|
|
|
Post by andruszamojski on Feb 24, 2020 8:58:59 GMT
Hi,
I have related question, now into latest Redfish spec 1.9.0.
Spec usually uses terms defined in Chapter 3. Terms and definitions like shall, should etc.
In chapter 11.2.4.3.2 Action with a response body there is such statement:
"A response body for an action is defined using ..."
Should it be treated as obligatory ('shall') or recommended ('should') for every action returning a JSON body?
|
|
|
|
Post by jautor on Feb 25, 2020 19:55:33 GMT
Hi, I have related question, now into latest Redfish spec 1.9.0. Spec usually uses terms defined in Chapter 3. Terms and definitions like shall, should etc. In chapter 11.2.4.3.2 Action with a response body there is such statement: "A response body for an action is defined using ..." Should it be treated as obligatory ('shall') or recommended ('should') for every action returning a JSON body?
Good catch! Yes, that is a "shall" statement - we'll fix that as an errata in the next release of the specification.
(and note that most Actions do not return a JSON payload - just an HTTP response code)
Jeff
|
|
|
|
Post by andruszamojski on Feb 26, 2020 9:55:45 GMT
Thank you for confirmation, we had same feeling, fortunately.
|
|
|
|
Post by andruszamojski on Mar 2, 2020 14:00:17 GMT
Is there any description/definition of how to describe actions which
* require input in different format than JSON - e.g. a file to be uploaded
* have output in format different than JSON - e.g. a file or XML content
I mean OEM actions of course.
|
|
