5:09 a.m.
>> The new design of logical network 'usages'
collection came out a
>> bit
>> problematic or shall i say annoying.
>> The idea is to send the entire collection elements every time a
>> user
>> wants to update a single usage otherwise the missing elements will
>> be
>> automatically removed from the collection.
>>
>> Example:
>> having <usages><usage>VM</usage><usages>
>> 1. in order to add 'display' usage to the collection i must send
>> 'vm'
>> as well.
>> 2. to remove an element from the collection, i must send the
>> entire
>> collection without the desired element
>> (note: in this case it is only one extra element for every update
>> but
>> in other cases it could be much more)
>
>
>Yep, this seems to conflict with the general idiom around the
>interpretation of missing properties in a PUT representation -
>i.e. any properties omitted from the representation are ignored
>and not changed.
>
**I'm going to explain the current modelling; this does not mean I
object to other modellings**
In the current modelling, usages are a non-trivial collection within
a
Network, but they are not business entities, and thus do not have
their
own 'context' (i.e, there's no: .../networks/{network:id}/usages).
A-ha, I see.
I was thrown by the overloading on the term "collection", which
I would have understood as a set of resources that may be addressed
as a group.
Whereas in fact we're more talking about an aspect of the Network
representation that happens to include boolean sub-elements, right?
In which case, making this explicit via your suggestion:
<usages><vm>true</vm><display>false</display></usages>
would seem reasonable on the face of it.
However there's an implementation wrinkle in the type-mapper
framework ...
I'd understand the PUT below as meaning:
"set the VM usage to true, and leave other usages as they are".
GET .../networks/{network:id} HTTP/1.1
200 OK
<network id="{network:id}">
...
<usages><display>true</display></usages>
</network>
--
PUT .../networks/{network:id} HTTP/1.1
<network id="{network:id}">
<usages><vm>true</vm></usages>
</network>
200 OK
<network id="{network:id}">
...
<usages>
<vm>true</vm>
<display>true</display>
</usages>
</network>
as things currently stand, the type mapper called prior to the
UpdateNetwork action being initiated doesn't have access to the
*existing* network entity, so it has no way of setting the is_display
flag on the mapped entity to match the pre-existing setting.
I guess you could work around this by forcing a network lookup *prior*
to the update, so that the pre-existing display setting is available,
and then pass this entity as a template into the type mapping.
>I wonder would a POST/DELETE idiom be more natural, if the
individual
>usages would be pressed into service as a psuedo-OID, e.g:
>[snip]
We'd need to develop an infrastructure for generating on-the-fly IDs
for internal,
non-entity, collections (based on a specified field)
Well, the idea was to avoid the need for generating on-the-fly OIDs,
by reusing the display "name" as the OID. But yes, it would still
involve some deviation from the established collection/sub-resource
implementation patterns.
Cheers,
Eoghan