narve
commented
2 years ago I see your points, but I disagree. There are several reasons for wanting to have them in an object. Typically a query will be very generic, e.g. /baselines, and the number of possible results is way to large to return all. How do we tell the client that there are more hits available, and how to get them?
The most obvious one is SearchResult.NumberOfHits, which is the number of hits the query returned. This could be 1500, while only 1000 (or 100) is actually returned in the Items array. If NumberOfHits>Items.Count, there are more hits available.
Furthermore, the links element should give hints on how to get the next hits, if any; typically with a Link with a relation-type of 'next', and a URL, e.g. /baselines?Skip=100 or /baselines?StartAt=234342 or something, depending on the implementation.
Furthermore, implementations are free to add more properties. In our case we would typically add more info, e.g. information about the search parameters (including defaults that were applied), embedded objects etc.
cdmNSIDE
If we remove the links, I think that the objects TradeSearchResult, BaselineIntervalSearchResult, OrderSearchResult, AssetPortfolioSearchResult and MeterReadingSearchResult are not strictly needed. We can simply return an array of Trades, an array of BaselineInterval, an array of Orders and so on. The number of hits returned can be deduced from the size of the arrays, isn't it ?