odata.navigationLink

I don't believe so. The intention of the @odata.nextLink field is to provide a mechanism to page resource collections that contain more data than can reasonably be returned in a single response. For example a System Event Log with 2000 entries or something of that nature. (I pick SEL as an example because LogService entries are meant to be expanded into the collection instead of linked via @odata.id, therefore a lot more data is rendered).

What the implementation might do in that circumstance is limit the number of resources that it will return in a collection (to 10, for example) and only return 10 of the entries in the collection instead of all 2000.

The collection's Members@odata.count field should still report the full number of resources in that collection, so @odata.nextLink is used to indicate how to read the next 10 entries (as without providing that, accesses to the URI will only ever return the first 10 entries).

So for example:

A GET on /redfish/v1/Managers/0/LogServices/SEL/Entries might return

{

"@odata.id": "/redfish/v1/Managers/0/LogServices/SEL/Entries",

"@odata.context": "/redfish/v1/$metadata#LogEntryCollection.LogEntryCollection",

"@odata.type": "#LogEntryCollection.LogEntryCollection",

"Description": "Log Entry Collection",

"Name": "SEL Log Entries",

"Members@odata.count": 2000,

"Members": [

{

...
"Id": "0", /* Note that the ID is 0 */
...

}, /* 10 times */

],

"Members@odata.nextLink": "/redfish/v1/Managers/0/LogServices/SEL/Entries?$skip=10"

}
And then if you follow the Members@odata.nextLink URI (/redfish/v1/Managers/0/LogServices/SEL/Entries?$skip=10):

{

"@odata.id": "/redfish/v1/Managers/0/LogServices/SEL/Entries",

"@odata.context": "/redfish/v1/$metadata#LogEntryCollection.LogEntryCollection",

"@odata.type": "#LogEntryCollection.LogEntryCollection",

"Description": "Log Entry Collection",

"Name": "SEL Log Entries",

"Members@odata.count": 2000,

"Members": [

{

...

"Id": "10",
/* Note that this ID is now 10 */
...

}, /* 10 times */

],

"Members@odata.nextLink": "/redfish/v1/Managers/0/LogServices/SEL/Entries?$skip=20"

}
You should be able to follow the @odata.nextLink all the way to the end of the collection, and you'll end up with the same data as you would if the resource was not paged.

I'm not a member of the DMTF or the working group, but this is my understanding of the Redfish specification (and OData in general).

Hope this helps!

Thanks,

Mark

In the context of a non-collection resource (such as Thermal), payloads cannot make use of the @odata.nextLink annotation. In addition, the Redfish spec does not call out the @odata.navigationLink annotation, so making use of those in implementations is outside the scope of standard Redfish.

Back to your example Thermal payload, you will need to add the expanded Temperatures, Fans, and Redundancy arrays like this. I would also recommend removing the @odata.navigationLink terms since Redfish-centric clients will unlikely be able to use them.

{
“@odata.context” : “/redfish/v1/$metadata#Thermal.Thermal”,
“@odata.id” : “/redfish/v1/Chassis/Enclosure/Thermal”,
“@odata.type” : “#Thermal.v1_2_0.Thermal”,
“Name” : “Thermal”,
“Id” : “Thermal”,
“Status” : {
“State” : “<See Table 1>”,
“Health” : “<See Table 1>”
},
“Temperatures@odata.count” : <count of temp sensors >,
“Temperatures” : [
{ <Temperature Object 0> },
{ <Temperature Object 1> },
{ <Temperature Object 2> },
...
{ <Temperature Object X> }
],
“Fans@odata,count” : <count of fans>,
“Fans” : [
{ <Fan Object 0> },
{ <Fan Object 1> },
{ <Fan Object 2> },
...
{ <Fan Object Y> }
]
“Redundancy@odata,count” : <count of redundancy records>,
“Reduncancy” : [
{ <Reduncancy Object 0> },
{ <Reduncancy Object 1> },
{ <Reduncancy Object 2> },
...
{ <Reduncancy Object Z> }
]
}

Apologies - I misread the title and thought the discussion was about @odata.nextLink!

Thanks for pointing that out; that does not seem correct and we'll have to check out our tool that converts CSDL schema to JSON schema.