OData or Queryable REST?

Before embarking on API development, looking to choose the right foundation.

So...OData permits queryability over models. Great!

...but REST apis can be decorated with the [Queryable] ...

So... what is the remaining advantage of OData over such Queryable APIs?

Maybe the following are true?

OData routing relies primarily on convention based routing, so not sure one can craft if ever needed to (e.g.: to avoid legacy routes one has to implement?)

Suspect one cannot query REST APIs based on child entities?

Anything else that would come into play?

Thank you!

Solution

OData is a specific and standardized implementation of REST. If you make your standard API endpoint's queryable then those specific endpoints will follow most of the OData v4 response conventions but it is up to you to document this for the consumers.

When you choose to start from OData, you are choosing to implement the OData conventional standards for all of the controllers and Entities that you choose to include in the OData Entity Model. This in turn will generate the $metadata document that describes the model and the supported functions and actions.

You can add custom types, functions and actions to an OData controller if you follow the conventions correctly. You can also directly host standard API controller endpoints if you want to, but unless you register them with the OData model, they will not be included in the $metadata document.

You could choose to replicate or implement the entire OData specification in your API from first principals if you want to, including producing your own $metadata document... But if you were going to go to all that trouble then it would have been far easier to just use the ODataController and implement OData properly.

Making the decision to use OData over standard Web API is usually driven by your chosen documentation method and if you can accept the general OData query conventions and if the consumers of the API can understand OData. OData standards are clearly defined so that you don't have to worry as much about educating consumers on how to use your API and can focus more on the implementation itself.