Closed andersy005 closed 12 months ago
Ooh good question! We do need to know the explicit project -> category mapping in order to accomplish the following:
It seems like explicitly returning info per project might be a clean/extensible way to do this anyway. This would look something like:
{
"projects": [
{
"project_id": "A",
"category": "foo", "bar"
},
{
"project_id": "b",
"category": "zar"
}
}
On production, it looks like these changes are showing up for /clips
but not /credits
-- why is that?
On production, it looks like these changes are showing up for
/clips
but not/credits
-- why is that?
initially, i didn't find the extended projects
field necessary for /credits
due to the 1-to-1
mapping between project and credits (a transaction belongs to a single project). therefore, i didn't consider adjusting it when we decided to explicitly map projects
and categories
for clips
(due to the 1-to-many relationship between clips
and projects
).
@katamartin, let me know if it would be convenient to have projects
with a single entry for /credits
{
...,
"projects" : [{"project_id" : "FOO", "category": ["a", "b"]}],
...
}
Ahhh right! Even knowing that there's a 1-to-1
relationship between credits and projects, I expected the two endpoints to be formatted similarly. Maybe a single project: {project_id, category}
entry could make sense for /credits
?
@katamartin, let's consider two projects, namely
A
andB
. these projects are associated with three categories, which are as follows:foo
andbar
.zar
.regarding the clips, are we looking to retrieve the following response?
i'm uncertain whether we need to know the mapping between categories and projects explicitly in
/clips
payload, or if it is necessary to include the explicit mapping betweenproject_ids
andcategory
.the most recent commit will produce a result that resembles: