In ODATA-954 we added support for composite keys expressed through key-as-segment, which begged the question what happens if only part of the key is specified. It seems reasonalbe that, in this case, we would do a partial filtering of the results.

i.e.;

AccountingDocuments/SAP/2016

would identify the subset of accounting documents for a company and year, and

AccountingDocuments/SAP

would identify the subset of accounting documents for a company.

Services could optionally support this as a shorthand for

GET AccountingDocuments?$filter=CompanyCode eq 'SAP' and Year eq '2016'

and

GET AccountingDocuments?$filter=CompanyCode eq 'SAP'

If supported, we should define consistent semantics across both key-as-segment and parens-syntax.

Note that the rules for disambiguation would be a little inconsistent. Normally we interpret a path segment first as a property, then as a function/action, then as a property. If we support partial keys then the resolution rules become a bit tricky – if the previous segment matches a partial key value then the next segment would be matched as a partial key value before anything else.

Note also that the same scenarios could be supported through filter.