Hi , As per Bios.v1_1_0.json, we have below details
It is likely that a client finds the `@redfish.Settings` term in this Resource, and if it is found, the client makes requests to change BIOS settings by modifying the Resource identified by the `@redfish.Settings` term.",
Based on SettingsObject, use can Patch to SD URI's and Initially there will be no etag for first time and how user can use etag in this scenario
If a client calls PUT or PATCH to update a resource, it should include an ETag from a previous GET in the
HTTP If-Match or If-None-Match header.
Do user needs to mention If-Match as "*" to patch for firs time or implementation needs to skip HTTP 428 status code for this URI for first time? Please explain for first time and subsequent patch operation after user patching some attributes to SettingsObject w.r.t etag Once applied to BIOS, etag will get updated and subsequent patch operation need to use this etag or not? I hope Post is not allowed as per Bios schema(Bios_v1.xml) and no details about post/patch operations in Settings_v1.xml, please confirm whether implementation can allow post which doesn't require etag for first time, second time onward patch can be used, but user will be confused of using both Post, Patch
I'm not sure I quite understand why there wouldn't be an ETag initially. Even if the settings resource for BIOS has not been touched by the user, the service will still expose the current settings data when a client performs a GET on the settings resource. Based on the data of the settings resource, the service should be providing some sort of ETag for it.
POST is certainly not allowed on this type of resource.
For the first time a client sets data on the resource, I would expect it to treat it like any other resource: perform a GET on the resource to determine the current state, then PATCH the resource for any changes required.
Hi, Thanks for the details. My assumption is /redfish/v1/Systems/1/Bios/SD will show only the attribute changes requested by user and not all the attributes.
So Initially if user is not requesting any change in attribute means, redfish/v1/Systems/1/Bios, /redfish/v1/Systems/1/Bios/SD will show same attributes. If both redfish/v1/Systems/Self/Bios, /redfish/v1/Systems/1/Bios/SD has same attributes, then same etag of redfish/v1/Systems/1/Bios can be used for /redfish/v1/Systems/1/Bios/SD, Please confirm
If user patches some attribute /redfish/v1/Systems/1/Bios/SD URI, then we need to show only attributes in get response of /redfish/v1/Systems/1/Bios/SD URI whichever n patched earlier (Not all the attributes), please confirm
I would expect all attributes to be in there, otherwise the client wouldn't know what they can PATCH when examining the settings resource. It's like any other resource; it would be very confusing to the client to be able to PATCH properties that do not exist in the resource. This becomes even more crucial on settings resources that are used in other places; if properties are not pre-populated in the settings resource, the client has no way of knowing what properties in the resource are controlled by the settings resource.
If no attributes are being modified, then I would expect the "Attributes" property in both the BIOS resource and the BIOS settings resource to be identical.
No, you'll still get all 500 attributes on the subsequent GET. Again, if there are properties in the resource that can be PATCHed, they need to be in the response from GET requests. Not showing all of them is not deterministic for the client and is against the general model for all resources.
For your example flow... 1. Client performs GET on the settings resource; 500 attributes are returned. 2. Client performs PATCH on settings resource; 1 attribute is changed. 3. Client performs GET on settings resource; 500 attributes are returned (only one has changed since the first step).
I also have a concern here. If there is no future settings set by the user, why do we need to return current settings in the GET method of Bios/SD URI? So I think User can POST data for first time to Bios/SD to let all other people know that some settings are available to apply. If any other user or the same user wants to modify he can with the help of PATCH.
If no data is set by the user then GET Bios/SD should return 404 so that it is easier for identification for all users as well as BIOS to know that no new settings need to be applied.
It's largely because the client otherwise has no indication of what they're allowed to set. Bios is fairly unique in that it's likely going to be everything in "Attributes", but for other resources, different systems have different architectures where different properties are going to be governed by the settings resource. I don't see how returning an error is helpful for the client when nothing is set. From a client's perspective, all that it would care about is what the properties will change to when the settings are applied. The general workflow for the settings resource is no different than any other resource:
1) The client performs a GET on a resource. 2) The client makes decisions based on the state of the resource. 3) If needed, the client performs a PATCH on the resource to set the resource to the desired state.