Consistency was used as an argument for either singular or plural
aliases vs aliaslist vs aliaslists were an interesting topic that swung us toward plurals always (as otherwise we would need to start using different terminology in order to reach consistency).

We could improve https://github.com/wmde/wikibase-rest-api-proposal/blob/master/DECISION-RESEARCH.md#resources-in-plural-vs-singular and possible link the principles doc to this research md too?

In terms of HAL we could also expand https://github.com/wmde/wikibase-rest-api-proposal/blob/master/SCOPE.md#response-links

TBA tickets for @Pablo-WMDE

The documented decision was about consistently using singular or plural for all path parts across resources - anticipating the notorious debate "singular or plural". The idea of consistently using plural for endpoints returning collections and singular for individual resources was not mentioned in this context at all.

The idea is a new concept to me. After a fair amount of unsuccessful searching I'd be interested in links to popular examples of that approach (and ideally arguments which compare approaches). To me it sounds a bit like combining the disadvantages of both sides (having inconsistent plurality & removing the "hackability" of a - by definition hierarchical - path).

As a supporting argument why "consistency" (in the original interpretation) in this case may not be a goal worth striving for, the desire for linking to be built into the API (e.g. HAL) was mentioned - that way client applications would not need any knowledge of URLs and would receive them as part of the responses (and hence not care about having to construct different ones for single entities or collections). The linking topic was mentioned but documented as out of scope.

I think this argument could go both ways - if nobody has to know the paths, why make the effort of differentiating. Picking up the discussion around the linking in the future again (ideally before transitioning to the implementation phase) sounds like a very worthwhile task irrespective of plurality to me however.

I'll see if I have ideas to further improve the documentation about the plurality decisions so far.

Merged the PR adding a tiny bit of docs here regarding plurality and the connection to link in responses.

Ok, you are right and my proposed mix of singular and plural resource names is probably rubbish.

While I'm convinced that collection resources (to be used with GET and POST) should always be plural, I may have misunderstood reasons for using singular resource names (such as given here and here) as an excuse to mix them both. However, on reading all this again, it seems clear that more importantly than using one or the other, it is to choose one and stick to it. Which also means, that giving "consistency" as the main and single reason here and here is just fine.