Misleading response for sinks under a receiver
cristian-recoseanu opened this issue · 10 comments
This
https://github.com/AMWA-TV/nmos-sink-metadata-processing/blob/2df7505b0657cbd55b3981a5a838b237f058e206/examples/resourcelist-get-200.json
suggests the response should be a list of URL suffixes effectively:
[
"c72cca5b-01db-47aa-bb00-03893defbfae/",
"171d5c80-7fff-4c23-9383-46503eb1c63e/",
"a2655c48-8a46-4c82-b9bc-98760d59d7f8/"
]I think this is misleading because this suggests you can actually navigate to these URL suffixes under the receiver endpoint and retrieve the sinks from there. But you can't.
I think we should change this to a json array response without the trailing slash because you are returning the IDs which should then be retrieved from the /sinks endpoint.
[
"c72cca5b-01db-47aa-bb00-03893defbfae",
"171d5c80-7fff-4c23-9383-46503eb1c63e",
"a2655c48-8a46-4c82-b9bc-98760d59d7f8"
]I agree, that it's misleading. I can also propose wrapping this array into a property of a JSON object.
I am in favor. It would match the usage of GUIDs in other APIs like IS-04 and 05
Was hoping to fix this before the meeting but, the schema forces the trailing / so it's not a trivial change... Might be easy to tackle this and #17 in one PR
Does it make sense to return resolved Sink objects from this endpoint as an array? If Controller needs them, it won't need to make an additional request; if it needs EDID binaries, it will be able to extract id property from each array item.
But the sink objects could be quite large and I'm not sure how many sinks would a typical device have.
Would such an array become very large?
I do however apreaciate it would save on the number of requests required to gather all the sinks.
I expect Sink is large, but each Receiver mostly has a single Sink.
It seems odd to have the Sink exposed in two locations 🤔
IS-04 acts similarly. Compare /flows/ and /flows/{flowId} although it's not the same case.
I agree it's odd to have sinks hosted under 2 endpoints. One also has the binary EDID API path which complicates things further.
I think we shouldn't make our lives harder at this point.
Should we just transform this into an array of string IDs without trailing slashes?
IS-04 acts similarly. Compare
/flows/and/flows/{flowId}although it's not the same case.
But in this case it would be receivers/id/sinks and sinks/id/properties which have the same contents
Should we just transform this into an array of string IDs without trailing slashes?
I think it's the easiest solution 👍