RelatedProperties vs MessageArgs | Redfish Specification Forum

ginugeorge
Minnow

Posts: 28

RelatedProperties vs MessageArgs Feb 7, 2023 12:10:18 GMT

Quote

Post by ginugeorge on Feb 7, 2023 12:10:18 GMT

Consider I am performing a PATCH operation on the Ethernet Interface Instance eth0 with the below request body :

https://{{ip}}/redfish/v1/Managers/Self/EthernetInterfaces/eth0

{

    "IPv6StaticAddresses": [

        {

            "Address": true,

            "Oem": {

                "Ami": {

                    "@odata.type": "#AMIIPV6.v1_0_0.AMIIPV6",

                    "StaticIPAddressIndex": 1

                }

            },

            "PrefixLength": 64

        }

    ]

}

If you see the above request body, we see that the Address attribute doesnt have a valid value associated with it and so we need to return 400 Bad Request with the appropriate error response body.

Please let us know which of the below mentioned response bodies are correct ?

Error Response Body Format 1 :

Here in the "Message" attribute, the property Address is represented as a RFC6901-defined JSON pointer representation, similar to what we have under the "RelatedProperties" attribute.

{
    "error": {
        "@message.ExtendedInfo": [
            {
                "@odata.type": "#Message.v1_0_8.Message",
                "Message": "The value 'true' for the property /IPv6StaticAddresses/0/Address is of a different type than the property can accept.",
                "MessageArgs": [
                    "true",
                    "/IPv6StaticAddresses/0/Address"
                ],
                "MessageId": "Base.1.12.PropertyValueTypeError",
                "RelatedProperties": [
                    "/IPv6StaticAddresses/0/Address"
                ],
                "Resolution": "Correct the value for the property in the request body and resubmit the request if the operation failed.",
                "Severity": "Warning"
            }
        ],
        "code": "Base.1.12.PropertyValueTypeError",
        "message": "The value 'true' for the property /IPv6StaticAddresses/0/Address is of a different type than the property can accept."
    }
}

Error Response Body Format 2 :

Here in the "Message" attribute, the property Address is represented normally, unlike the "RelatedProperties" attribute, which is represented as a RFC6901-defined JSON pointer representation.

{
    "error": {
        "@message.ExtendedInfo": [
            {
                "@odata.type": "#Message.v1_0_8.Message",
                "Message": "The value 'true' for the property Address is of a different type than the property can accept.",
                "MessageArgs": [
                    "true",
                    "Address"
                ],
                "MessageId": "Base.1.12.PropertyValueTypeError",
                "RelatedProperties": [
                    "/IPv6StaticAddresses/0/Address"
                ],
                "Resolution": "Correct the value for the property in the request body and resubmit the request if the operation failed.",
                "Severity": "Warning"
            }
        ],
        "code": "Base.1.12.PropertyValueTypeError",
        "message": "The value 'true' for the property Address is of a different type than the property can accept."
    }
}

Last Edit: Feb 7, 2023 12:26:26 GMT by ginugeorge

mraineri
Administrator

Posts: 1,050

RelatedProperties vs MessageArgs Feb 7, 2023 13:42:43 GMT

Quote

Post by mraineri on Feb 7, 2023 13:42:43 GMT

Since the long description of for the argument is "This argument shall contain the name of the property.", then format 2 is correct; the long description just states the name of the property rather than the full property path.

Keep in mind, these message strings are intended to show up in user interfaces, so having a full path might be strange for a user who does not code to encounter.

shawn
Minnow

Posts: 16

RelatedProperties vs MessageArgs Feb 8, 2023 1:27:05 GMT

Quote

Post by shawn on Feb 8, 2023 1:27:05 GMT

Isn't it more straight forward to show full path? Like this example, with full path, it helps a user to indicate which item includes incorrect value of one of many property in many items.

Besides, I thought the full path is for the context instead of any code of it. I'm not sure why it relates to code.

mraineri
Administrator

Posts: 1,050

RelatedProperties vs MessageArgs Feb 8, 2023 13:39:07 GMT

Quote

Post by mraineri on Feb 8, 2023 13:39:07 GMT

I human interacting with a Redfish GUI isn't going to necessarily know about JSON payloads or any other internal structures involved with Redfish. A user that only sees a pop-up containing the message string that refers to "/IPv6StaticAddresses/0/Address" is going to be strange for them. That's why "RelatedProperties" is in the message object; the GUI can use the information in RelatedProperties to better handle things internally and present the message string to an end user as-is without the need to manipulate the string.

shawn
Minnow

Posts: 16

RelatedProperties vs MessageArgs Feb 9, 2023 1:44:16 GMT mraineri likes this

Quote

Post by shawn on Feb 9, 2023 1:44:16 GMT

Ah! I see why we think of it differently. I thought that humans directly interacted with the Redfish service itself. However, in most cases, there are thousands of servers that need to be controlled by a tool or GUI. In that case, all information can be summarized by it, allowing humans to perform critical tasks.

Thanks, mraineri. Always learned a lot from you.

mraineri
Administrator

Posts: 1,050

RelatedProperties vs MessageArgs Feb 9, 2023 13:22:29 GMT shawn likes this

Quote

Post by mraineri on Feb 9, 2023 13:22:29 GMT

Exactly! People on this forum are all very comfortable working with JSON and interacting with Redfish services directly, but jumping up the stack, people working in field service may have no idea what Redfish is, but are using Redfish tools.