Q:

ASP.NET MVC API vs Web API Async

I current am using ASP.NET MVC and a single Controller for an "API" of sorts. I am using a Service/Repository pattern called from each action method.
Similar to below:
Repository:
    public IQueryable<Order> GetOrders()
    {
        return from sqlOrder in DB.Orders
               select new Order
               {
                   Id = sqlOrder.Id,
                   Name = sqlOrder.Name,
                   Price = sqlOrder.Price
               };
    }

Service:
    public List<Order> GetOrders()
    {
        return Repo.GetOrders().ToList();
    }

Controller/Action:
    public JsonResult GetOrders()
    {
        var orders = Service.GetOrders();

        return Json(orders, JsonRequestBehavior.AllowGet);
    }

Everything is working great, however I'm considering moving over to WEB API and Async/Await 
Similar to below:
Repository: (no change)
    public IQueryable<Order> GetOrders()
    {
        return from sqlOrder in DB.Orders
               select new Venue
               {
                   Id = sqlOrder.Id,
                   Name = sqlOrder.Name,
                   Price = sqlOrder.Price
               };
    }

Service:
    public async Task<List<Order>> GetOrders()
    {
        return await Repo.GetOrders().ToListAsync();
    }

Controller/Action:
    [ResponseType(typeof(List<Order>))]
    public async Task<IHttpActionResult> GetOrders()
    {
        var orders = await Service.GetOrders();

        return Ok(orders);
    }

First, are there any problems with this async/await and Repository pattern? 
Are there any major downsides to using the raw MVC framework as an "API" of endpoints? Instead of using "Web API"?

A:

You've pretty much answered your own question :)

By using async/await the iis worker thread can re-use a thread. Suppose your api is receiving 1000 calls / second. If your thread limit is set to 100 then 900 calls will wait idle untill a request is fully finished.
By using async/await however the threads will be assigned sooner to the 900 waiting requests and the load will reach your database sooner(and harder).
imagine you have a maximum thread count of 1, 1 db call which lasts 10 secs and a server that can start a db call from a webrequest in 50ms. 
By using async you could fire up 200 db calls (1 per every 50 ms) vs 1 if you don't free up that thread.

As for your second question : most people don't do their data access inside their controller but it makes a very clean & simple to understand example.
If my project is simple enough(think grid screens) i even prefer using EF statements inside the controller vs creating a DAL layer. Don't forget that EF is a repository itself, it even has a unit of work build in ...
edit
It is indeed a good idea to wrap your businessLogic in a seperate layer from your controller.
You could use services and expose a method per query you want to do but i've been down that road and i usually find that my services get bloated rather fast as developers make more and more methods as they see fit.
Lately i adopted the command query system. A query just returns data and a command just does something. The seperation helps to keep to code cleaner and developers put more thought into creating a whole new queryClass as they would when they create just a method(even though the impact is the same).
I usually make my queries a bit dynamic but not too much.
For example an OrderQuery could contain 2 constructors, 1 with customerID and 1 with typeID) the query would then apply a filter more or a filter less depending on how it was constructed.
If i needed say all the latest orders which have a sales value of more then X i would probably create a new query GetOrdersByValue. This way the query itself can stay clean and focussed(which results in more speed and developers not reinviting the wheel because they recognise that their request should already exist).

