|
|
Post by sdurbin on Mar 9, 2023 19:05:00 GMT
Hello, I had a question regarding @odata.id in some of the responses that I'm seeing in the mockups: I'm wondering why some object arrays that are nested in entities contain the @odata.id, and some don't. For example, in the response: redfish.dmtf.org/redfish/mockups/v1/1266#Chassis--1U--Thermal, the array of Temperature objects have an associated @odata.id, but in redfish.dmtf.org/redfish/mockups/v1/1266#Managers--BMC--EthernetInterfaces--eth0, the nested arrays of objects do not contain an @odata.id.
I don't think either are specified as collections and the Temperature objects are specified as an object in the Thermal schema. I have looked through the ODATA specifications and feel like I'm missing something here. Thank you for any help/guidance. -Steve |
|
|
|
Post by mraineri on Mar 9, 2023 19:27:10 GMT
There are some object definitions in Redfish that follow a base definition of "ReferenceableMember", which stems from an "EntityType" definition rather than a "ComplexType" definition. In short, anything defined with "EntityType" has the @odata.id property (which is more formally the entity identifier). The history behind it is very OData-based where we wanted to express links with NavigationProperties to individual things in a resource with an @odata.id. When you look at the schema definition for this (CSDL in particular) these properties are called out with NavigationProperty with AutoExpand set to true, which forces the expansion of the referenced entity in the payload. In Redfish, these types of objects are not directly accessible; the JSON Pointer notation is used in the URI to express where in the referenced resource the object exists.
We do have the following statement in the "Structured properties" clause of the Redfish Specification about using @odata.id for these types of objects: "Some structured properties inherit from the Resource.v1_0_0.ReferenceableMember definition. Structured properties that follow this definition shall contain the MemberId and resource identifier properties."
We did this on only a few cases (like PowerSupplies in Power and Temperatures in Thermal). However, this type of modeling pattern has been very confusing to most users, and newer models published by the forum have been avoiding this practice.
|
|
|
|
Post by sdurbin on Mar 10, 2023 4:46:07 GMT
Thank you very much for the explanation. I'll take a look deeper into the CSDL/ReferencableMember.
|
|
|
|
Post by jautor on Mar 10, 2023 19:15:43 GMT
Thank you very much for the explanation. I'll take a look deeper into the CSDL/ReferencableMember. Please don't...  We've moved away from any future use of the "ReferencableMember" concept because it drove a design pattern using arrays rather than Resource Collections. Over time it's become clear that for cases where you would want to be able to reference an object "that big", it should be its own resource. The `Power` and `Thermal` schemas have both been deprecated in favor of `PowerSubsytem` and `ThermalSubsytem` that both use a number of Resource Collections in place of those large embedded objects. There are collections for `Fan` and `PowerSupply` resources, for example. If you are starting a new implementation, and don't have client requirements to the "old" Power and Thermal definitions, we would recommend that you skip those completely and use their replacements. Jeff |
|
