There is no reason for ODataResult to exist.
1. You don't need it to know to return an OData Formatted result back because the media formatter does this.
2. You don't need it to know the URI for the next page.
3. You don't need it to know to return the count, this is done by the request having $inlinecount=allpages on it and there is no reason for this to be pre-calculated because you already have access to the query before the $filter and $take/$top/$skip are filtered so you can get it easily with .Count()/.LongCount()
Thus it's redundant.
If QueryableAttribute is applied to the request, then if using pure json it should return a value like this:
{
result: [
{
result 1 info
}
]
}
if $inlinecount requested then it should put it, using the same name as standard odata like this:
{
result: [
{
result 1 info
}
],
linecount: 10 //This should be whatever the standard odata name is, I don't know what it is.
}
if $metadata is requested it should append that the same way in odata strucutre.
If the odata data type is specified as the responseType, then it should return a fully structured odata response in either json or xml based on the $format attribute.
The are two reasons why all Queryableattribute items should be formatted this way:
1. Returning a json array of results as the root has a massive security vulnerability in most browsers.
2. This allows for a tight syntax for results without requiring the full odata syntax when just wanting json back and allows for the count etc. to be there (and any other meta data that you want to return)
1. You don't need it to know to return an OData Formatted result back because the media formatter does this.
2. You don't need it to know the URI for the next page.
3. You don't need it to know to return the count, this is done by the request having $inlinecount=allpages on it and there is no reason for this to be pre-calculated because you already have access to the query before the $filter and $take/$top/$skip are filtered so you can get it easily with .Count()/.LongCount()
Thus it's redundant.
If QueryableAttribute is applied to the request, then if using pure json it should return a value like this:
{
result: [
{
result 1 info
}
]
}
if $inlinecount requested then it should put it, using the same name as standard odata like this:
{
result: [
{
result 1 info
}
],
linecount: 10 //This should be whatever the standard odata name is, I don't know what it is.
}
if $metadata is requested it should append that the same way in odata strucutre.
If the odata data type is specified as the responseType, then it should return a fully structured odata response in either json or xml based on the $format attribute.
The are two reasons why all Queryableattribute items should be formatted this way:
1. Returning a json array of results as the root has a massive security vulnerability in most browsers.
2. This allows for a tight syntax for results without requiring the full odata syntax when just wanting json back and allows for the count etc. to be there (and any other meta data that you want to return)