|
|
Post by AMI_ivywang on Sept 19, 2022 8:46:51 GMT
Hi,
1. What will be the expected response in this case?
PATCH https://{{ip}}/redfish/v1.Deep
----request body---
{
"Managers": {
"@odata.id": "/redfish/v1/Managers"
}
}
(Reference: Schema file "ManagerCollection.json" > "definitions" > "ManagerCollection" > "updatable": false)
2. What will be the expected response, <405 MethodNotAllowed for "/redfish/v1/Managers"> or <400 PropertyNotWritable for #/Managers/Members>?
PATCH https://{{ip}}/redfish/v1.Deep
----request body---
{
"Managers": {
"@odata.id": "/redfish/v1/Managers",
"Members": []
}
}
(Reference: Schema file "ManagerCollection.json" > "definitions" > "ManagerCollection" > "updatable": false)
Thanks,
Ivy
|
|
|
|
Post by mraineri on Sept 20, 2022 20:20:31 GMT
"MethodNotAllowed" is used when the service needs to reject the usage of the method entirely, as in the client cannot issue PATCH against the URI. Since PATCH is legal on the deep URIs, PropertyNotWritable makes more sense when a client is modifying something that is read-only within the request payload.
|
|
|
|
Post by AMI_ivywang on Sept 21, 2022 1:45:04 GMT
Hi,
One more question.
If here's no property to be modified in the deep patch request, like the example (A) as below.
Can the example (A) be considered the same as example (B) and return 204 No Content?
example (A):
PATCH https://{{ip}}/redfish/v1/Managers.Deep
----request body---
{
"Members": [
{
"@odata.id": "/redfish/v1/Managers/Self"
}
]
}
>> Return 204 No Content ?
example (B):
PATCH https://{{ip}}/redfish/v1/Managers/Self
----request body---
{}
>> Return 204 No Content
Thanks,
Ivy
|
|
|
|
Post by mraineri on Sept 21, 2022 13:00:52 GMT
Yes, the two are the same. In both cases, you're not modifying anything, and 204 No Content is an acceptable response.
|
|
|
|
Post by AMI_ivywang on Sept 21, 2022 13:06:43 GMT
Thanks for the reply.
|
|
|
|
Post by AMI_ivywang on Dec 8, 2022 9:40:43 GMT
Hi,
Should these 2 cases return the same response because "Test" is a unknown property?
Or can the case 2 return other error message like "{Oem}.1.0.DeepOperationResourceNotFound" due to "Request body will be parsed and use the property name (Test ) + @odata.id value(/redfish/v1/SessionService ) to find the resource exist or not." ?
1. PATCH https://{{ip}}/redfish/v1.Deep
{
"SessionService": {
"@odata.id": "/redfish/v1/SessionService",
"Test": 50
}
}
Response >> status code 400 with error message "Base.1.12.PropertyUnknown"
2. PATCH https://{{ip}}/redfish/v1.Deep
{
"Test": {
"@odata.id": "/redfish/v1/SessionService",
"SessionTimeout": 50
}
Thanks,
Ivy
|
|
|
|
Post by mraineri on Dec 8, 2022 14:52:01 GMT
If deep operations are not supported on service root, then it would return a 404 since "/redfish/v1.Deep" is not a valid URI for the service.
If deep operations are supported, both cases would return 400 with the "PropertyUnknown" message from the Base Message Registry. Case 1 would specifically call out "Test" in the SessionService resource as the unknown property, and case 2 would call out "Test" in the ServiceRoot resource as the unknown property.
|
|
|
|
Post by AMI_RythonCai on Dec 13, 2022 3:38:30 GMT
Hi,
What will be the expected response in this case ? can we return the DeepOperationResourceNotFound or something else ?
PATCH /redfish/v1.Deep
--- request body ---
{
"SessionService": {
"@odata.id": "/redfish/v1/test",
"SessionTimeout": 50
}
}
--- end ---
Thanks,
Rython
|
|
|
|
Post by mraineri on Dec 13, 2022 14:19:01 GMT
@odata.id is only used when performing a deep PATCH to members of a resource collection; in other cases, it's ignored, as stated in the PATCH (update) clause of the spec. However, if this example were showing a deep PATCH with members of a resource collection, there are two possibilities for responses here that come to mind:
If the desire is to allow partial success (where other properties were successfully updated), you would return 200 OK, and in-line use the @message.ExtendedInfo annotation to include the "InvalidURI" message from the Base Message Registry.
If the desire is to reject the request entirely (no successful modifications), 400 Bad Request with the same "InvalidURI" message in the response body to show the invalid usage of @odata.id for the collection member. Since the ".Deep" URI is valid, 404 shouldn't be used here.
I don't see a strong need to make a new message unique for deep operations for invalid URIs; given the context of the operation along with the response codes, the client should have enough information to understand that it provided a bad URI for an @odata.id property in the request body.
|
|
|
|
Post by AMI_RythonCai on Dec 14, 2022 7:55:44 GMT
I got it. Thanks for your reply.
|
|
