Let's take a step back and think about WebAPI. WebAPI is essentially a raw data delivery mechanism. This is great for creating an API, and it raises the separation of problems to a pretty good height (in particular, troubleshooting user interface problems).
Using the Web API, however, does not change the essence of the problem you are facing. You ask: "How can I execute a query in my data warehouse and efficiently transfer data to the client?" Your decisions here are really parallel to the same question when creating a more traditional web application.
As you noted, oData is one way to return this information. The advantage here is well known and well defined. The body of questions / blogs / articles on this topic is growing rapidly. The wrapper does not add any significant overhead.
However, oData is far from the only way to do this. We had to deal with this because the software was showing search results. It is difficult to give you specific advice without understanding your scenario. Here are some questions that I started reading when I read your question:
- Are your results huge, but users only see the first or two pages?
- Or can the user view all the results?
- Are results pages limited (e.g. 20 or 50 per page) or 100 or 1000?
- Does the dataset install quickly, so records are added as the user swaps?
- Are your results short and columns are added that repeat valid ones?
- Do you have enough control over the client to do something out of band - like custom HTTP headers or a separate HTTP request that just asks for a summary of the request?
There are indeed hundreds of options, depending on your needs. I do not know what you are using as a data warehouse, but I wrote a message about the effective number of rows . The problems there are very relevant here, although from the point of view of the database. This may help you get some perspective.
EBarr source share