Provide endpoint listing product labels

[ralphbean]

It would be nice to be able to list all known product labels with a new endpoint.

[hluk]

How would it be used? Would it be OK to paginate the response? (There is over 1000 labels.)

> http -b http://127.0.0.1:5000/api/v1.0/labels
[
    {
        "name": "ABC"
    },
    ...
    {
        "name": "XYZ"
    }
]

[ralphbean]

How would it be used?

Just by humans (like me) to see what valid strings look like. I later figured out I could access composedb directly with a readonly account to write sql to list the available labels - I'm unblocked.

Would it be OK to paginate the response? (There is over 1000 labels.)

Yes, that's fine as long as it's not too much work.

[hlin]

How would it be used? Would it be OK to paginate the response? (There is over 1000 labels.)

> http -b http://127.0.0.1:5000/api/v1.0/labels
[
    {
        "name": "ABC"
    },
    ...
    {
        "name": "XYZ"
    }
]

Would it be better to use 'label' as key?

[
{
"label": "ABC"
},
...
{
"label": "XYZ"
}
]

And I'm thinking why not just return a flat list, e.g.

[
    "label1",
    "label2",
...
]

[hluk]

Would it be better to use 'label' as key?

I'm OK with that, not sure which name makes more sense. @ralphbean Any preference?

And I'm thinking why not just return a flat list

The problem with the flat list is that it cannot be extended without breaking the API (in future we may want to add product count or list of products using the label).

BTW, making the result paginated later would also break API. I didn't make it paginated because it seems that it wouldn't currently save any CPU cycles; doing

SELECT DISTINCT label FROM products LIMIT 20 OFFSET 0;

is fast (<1ms), but

SELECT DISTINCT label FROM products LIMIT 20 OFFSET 100;

has same performance as asking for all 120 results (~20ms).

Taking just a few first labels doesn't make much sense anyway unless there is some form of filtering.

[hlin]

I see. Then the patch is ok me.

[ralphbean]

I'm OK with that, not sure which name makes more sense. @ralphbean Any preference?

I guess label makes more sense (it is self-consistent since the other endpoints ask people for a "label").