Efford needed to implement relatively simple OData API

[dnperfors]

It is this time of the year where you reflect on things. And OData is one of them for me.

In the last couple of months my team and I have been implementing a really straightforward read-only OData api.
The model currently contains 6 types, including a base type with 2 derived types and relationships between the types. Fairly straight forward.

What we found out is that when we would implement every interesting endpoint, we get a lot of endpoints, especially for the base type/derived types combination and their relationships:

1. /basetype
2. /basetype({key})
3. /basetype({key})/derivedtype1
4. /basetype({key})/derivedtype2
5. /basetype({key})/basetyperelationship
6. /basetype({key})/derivedtype1/basetyperelationship
7. /basetype({key})/derivedtype2/basetyperelationship
8. /basetype({key})/derivedtype1/derivedtype1relationship
9. /basetype({key})/derivedtype2/derivedtype2relationship

This basically leads to 9 methods on the controller from which part of them do exactly the same thing. Of course this can be solved by using attribute routing, but then you lose automatic support key as segment (which we also want to support).

Testing wise this actually becomes a nightmare. Especially when you allow query options like $select and $filter, you need to functionally test most of not all possible options, since mistakes are easily made, both in this library as in the configuration of the application. When supporting only $expand, we found that we soon had a couple of hundred test cases (which can partly be easily be automated).
One of the reasons I want to test most of it, is because I don't really trust the library and that I have to work around several issues we encountered.

This made me wonder, how do other people tackle this? Are you implementing every relationship endpoint, or do you use some dynamic controller instead? Are you actually testing all the options, or are you relying on the library?