|
|
Post by hramasub on Sept 12, 2016 3:15:11 GMT
About retrieving individual properties, the spec in section 6.4.2.4 states as follows: 6.4.2.4. Resource retrieval requests Clients request resources by issuing GET requests to the URI for the individual resource or resource collection. The URI for a resource or resource collection may be obtained from a resource identifier property returned in a previous request (for example, within the links clause of a previously returned resource). Services may, but are not required to, support the convention of retrieving individual propertiesof a resource by appending a segment containing the property name to the URI of the resource. The spec does not provide an example for the above descriptive text. Specifically, what is the syntax for the segment with property name? Are these valid formats of the URI for retrieving the properties of the System resource ? Serial Number of the System : abc.oem.org/redfish/v1/Systems/437XR1138R2/SerialNumberStatus complex property of the System : abc.oem.org/redfish/v1/Systems/437XR1138R2/StatusWhole of the Oem property of the System : abc.oem.org/redfish/v1/Systems/437XR1138R2/Oem |
|
|
|
Post by j2hilland on Sept 12, 2016 14:42:12 GMT
They are technically valid but since it is a may, Clients should be written to not depend on a Redfish Service to be able to respond to the Request. In fact, I don't know of any that currently support this syntax.
Redfish is a hypermedia API. That means Clients should not construct URIs. The best way to ensure a service will be able to respond to your request is to do a GET on abc.oem.org/redfish/v1/Systems/437XR1138R2/ and look for the SerialNumber property in the Response payload.
|
|
|
|
Post by saurabhvaidya on Dec 14, 2018 2:29:34 GMT
So does that mean it is best to hardcode URIs. For example:
the processor uri should be hardcoded to /redfish/v1/Systems/{vendor_format}/Processors/CPU.1
How is the code generic then. Will the URIs never change across versions??
|
|
|
|
Post by jautor on Dec 14, 2018 21:12:54 GMT
So does that mean it is best to hardcode URIs. For example: the processor uri should be hardcoded to /redfish/v1/Systems/{vendor_format}/Processors/CPU.1 How is the code generic then. Will the URIs never change across versions?? No, you should NOT hard-code URIs. Starting with Redfish v1.6, many URIs will be defined by the specification, at least to a point. The Processor collection, from your example, would always follow the format of: /redfish/v1/Systems/{vendor_format}/Processors/{vendor_format} Note that I corrected your example - the name of the CPU instance is also chosen by the vendor/implementation. But v1.6 is a very new version of the specification, and probably not supported yet in any shipping products. Now, most implementation generally followed the formats specified in the schema release 2018.2 (part of the v1.6 release) - which is how we decided what URIs to use... But there are some exceptions, so until the Service reports "RedfishVersion" of "1.6.0" or above, it's not a guarantee. The right way to discover these links is to read the ServiceRoot (which must be at \redfish\v1) and then use the hypermedia links to the other resources, and repeat that for each link as you traverse the tree. Jeff |
|
|
|
Post by saurabhvaidya on Dec 14, 2018 22:37:27 GMT
Yes, exactly I was trying to make it generic , still working on it.
But as of now the servers I work on are only at redfish 1.0.2 and I think it will be long before we upgarde the firmwares and redfish.
So in my case how will you advise me to write generic code. Atleast the most generic I could do.
I am writing code (only GET's) for now for dells, hps and smcs.
|
|
|
|
Post by mraineri on Jan 8, 2019 19:19:50 GMT
The way to approach this is by using discovery via hypermedia. Prior to 1.6.0, there are a couple of standard URIs that work across all services. You can safely start crawling the service from the Service Root (/redfish/v1), and follow the URIs referenced in that resource, and subsequent resources as needed.
For example, one generic way to retrieve all thermal information is to perform the following:
1) Perform a GET on the Service Root resource (/redfish/v1)
2) Perform a GET on the URI referenced by the "Chassis" property in the Service Root resource
3) Perform a GET on each URI referenced by the "Members" property from the response in step 2
4) Perform a GET on the URI referenced by the "Thermal" property from the responses in step 3
You should be able to perform a similar methodology with regards to firmware update; you'd start at the Service Root, find the Update Service, find the Software Inventory components referenced by the Update Service, then perform Actions on each of the discovered Software Inventory components.
|
|
