|
Post by James Harris on Nov 4, 2016 23:38:25 GMT
When a POST request to the EventDestinationCollection resource occurs, the body of the request follows one of the following two formats (one is correct, the other is most likely incorrect):
1: Destination (The client endpoint they want to receive POST requests to), EventTypes (an array of event types), Context (user provided key for the client’s server to interpret)
2: Resource @odata.id (The resource which the client wants to receive events from) Destination (The client endpoint they want to receive POST requests to), EventTypes (an array of event types), Context (user provided key for the client’s server to interpret)
Note, my confusion is based on whether or not,
"Resource @odata.id (The resource which the client wants to receive events from)"
is included in the POST request to the EventDestinationCollection resource. There's a moderate difference in the amount of logic necessary to implement the latter over the former, so I just want to ensure my understanding is correct in that #1 is correct.
Thank you very much!
|
|
|
Post by James Harris on Nov 4, 2016 23:55:29 GMT
Also, my confusion originated from the schema definition for redfish.dmtf.org/schemas/EventDestination.v1_1_0.jsonSpecifically, the "OriginResources" object in the properties object. Rather, I wasn't sure if the client actually included "OriginResources" in their POST request or not
|
|
|
Post by j2hilland on Nov 7, 2016 15:41:12 GMT
@odata.id is a read-only property, so wouldn't be part of the post. It will be returned in the body and would be the "self" pointer for the resource created, thus the service side would create it. Clients don't get to pick the URI they want to create in Redfish.
OriginResources is different - and is new. It allows clients to pick which URIs they want to receive events about. Expect most implementations to not support this one for quite a while. It's really for aggregators and Swordfish where more resources are available to provide advanced functionality.
|
|
|
Post by gericson on Jan 24, 2017 16:40:47 GMT
Adding to Jeff's reply. OriginResources allows a subscriber to limit the subscription to only those events generated by: a specified resource, a resource in a specified collection, a subordinate resource of a specified resource. In the Redfish world, OriginResources might refer to a specific Chassis, this would cover that Chassis as well as Thermal and Power and their underlying resources.
Note the OriginResources is specified as a collection of Resource.Item. This gives the subscriber some added flexibility in refining the subscription. For example, this allows OriginResources to be limited to a specific PowerControl entity.
|
|
|
Post by jack on May 16, 2017 7:36:23 GMT
Adding to Jeff's reply. OriginResources allows a subscriber to limit the subscription to only those events generated by: a specified resource, a resource in a specified collection, a subordinate resource of a specified resource. In the Redfish world, OriginResources might refer to a specific Chassis, this would cover that Chassis as well as Thermal and Power and their underlying resources. Note the OriginResources is specified as a collection of Resource.Item. This gives the subscriber some added flexibility in refining the subscription. For example, this allows OriginResources to be limited to a specific PowerControl entity. Does this mean that if a subscriber specifies "/redfish/v1/AccountService/Accounts" as one item of OriginResources, then the event receiver will receive events about all account added events, and account removed events, not just the account collection updated event?
|
|