/api/run should give an error when params are not specific enough

[Hexcles]

https://github.com/web-platform-tests/wpt.fyi/tree/master/api#apirun

The endpoint takes two params, product and sha, but they are not guaranteed to uniquely identify a test run (e.g. we have stable and experimental versions for the same product on a given SHA). In this case, /api/run arbitrarily returns one run that satisfies the filters (I think it's in fact the last created one, which is still "arbitrary" from a user's perspective). We should instead return an error.

Furthermore, I think /api/run should also take a labels param. The current approach of taking browser[version[os[version]]] as product may not scale well in the future because of #258 and the possibility that even the full (browser, version, os, version, sha) vector won't be unique enough.

[Hexcles]

In fact, we might as well get rid of this endpoint. IMHO it's a bit redundant with /api/runs and /api/runs/{id}. @lukebjerring what's the use case of this API?

[lukebjerring]

The behaviour of selecting the most recent run that matches the product is very deliberate. This endpoint is intended to bypass the need to 'fetch all the runs for a criteria and grab the latest one', as that use-case would be significantly less performant for loose queries (e.g. chrome@latest).

[Hexcles]

Then is it same as /api/runs?...&max-count=1?

[lukebjerring]

No; that:

• Returns an array
• Returns a max of 1 items per product, rather than in total, so if you have an ambiguous product/sha combo, you'll still get multiple results.

[lukebjerring]

The use of max-count > 1 ties into #315

Our current status, now that product params are supported, is that you can achieve the same thing that /api/run does with /api/runs?max-count=1, so I agree, let's drop the singular endpoint.

[lukebjerring]

Logs show that at least one person has fetched runs via this endpoint in the last week, so might not be fair to just drop the endpoint.