Trying to find out which is better with WebAPI and why.
[HttpGet]
public IEnumerable<Invoice> GetInvoices()
{
...
}
OR
[HttpGet]
public Invoice[] GetInvoices()
{
...
}
Thanks.
Loading User Information from Channel 9
Something went wrong getting user information from Channel 9
Loading User Information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
Trying to find out which is better with WebAPI and why.
[HttpGet]
public IEnumerable<Invoice> GetInvoices()
{
...
}
OR
[HttpGet]
public Invoice[] GetInvoices()
{
...
}
Thanks.
Better for what?
@wsdotnet: Neither ... use IQueryable. http://codebetter.com/johnvpetersen/2012/03/22/bringing-odata-to-your-webapi-just-use-iqueryable/
If for some reason you won't, IEnumerable is preferable because it's the interface for all synchronous collections in .NET, including arrays.
@FuncOfT: It would be preferable for regular APIs, but I don't think it really matters much in a WebApi. You don't know what's on the other end of the wire and have no control over what local data type they use in any event, so API design considerations here matter little. There's no difference in the resultant wire transfer, performance or functionality. The only reason to prefer IEnumerable<T> to an array would be if your underlying data wasn't an array to begin with... which we can't determine from the question.
But yeah, IQueryable would be preferred.
@cbae: performance.
6 minutes ago, wsdotnet wrote
@cbae: performance.
Both are exactly the same for performance, because the dominating effect is the cost of the network between your customer and your website.
Approximately exactly.
Within a few cycles, unlike the hundreds of millions of cycles you'll lose if a single TCP packet en-route gets dropped.
It doesn't matter for performance or features. But you might want to pick the array form just because it takes less space on the screen.
@warren:
It's also easier to pronounce.
Add your 2¢