As Robert Harvey mentioned in his comment, a web API is part of the application layer. An application layer is usually something that sits between the presentation layer and the business logic, translating GUI actions into/from messages understood by the objects in the business logic (for example, HTTP requests into method calls, and method results into HTTP responses). As its name says, it controls application logic, how the user interacts with the GUI, controlling screen navigation, etc.
However, I'll provide an answer based on your definition:
I have a Web API project which has all the Web API methods for CRUD and I have another Application Service project will store application logic
Think about it, why do you have the WebAPI if you will connect the presentation layer directly to your application service project? Also, think about what kind of messages the WebAPI and the Application layer are handling. Does your Application layer handle HTTP requests directly? I'll assume it most likely does not, but is a library that the WebAPI calls.
So, for your question, I think you will have this setup:
Presentation layer <-> WebAPI <-> Application layer
EDIT: You will often find applications with the following layers:
Presentation layer <-> Application layer <-> Service layer <-> Persistence layer
The application layer is a thin layer that offers services to the presentation layer, maybe some coordination for the interactions with the user, and has the important role of decoupling the presentation technologies from the rest of the application. The user might interact with a mobile app, or a web page, which send requests over HTTP. The business logic of your application shouldn't have to deal with HTTP, or HTML, for example, even though that's how you communicate with the user. So the application layer converts messages back and forward to decouple the presentation from the business code. This way, you can keep the same business functionality and expose it in different ways to the user.
The service layer (sometimes called the business layer) deals with the business rules and logic of your application. It's what your application actually does. It can often also provides a transactional boundary for the persistence layer in case multiple data access objects need to be coordinated to fulfill the business goals.
The persistence layer deals with the data access needs of the application. Similar to the presentation layer, this layer is often coupled to technologies like SQL, the file system, maybe web services over HTTP or SOAP.
There are of course many variations of these. In a 3-tier application for example, the presentation layer and the application layer form the presentation tier, while the service layer forms the application tier (1 - presentation tier, 2 - application tier, 3 - data tier). In some cases, depending on the technologies used for the GUI, the role of the application layer is handled by the presentation layer. In some instances there might be a layer in between the service layer and the persistence layer that decouples the two and converts messages back and forward, although in case of SQL data sources that's usually not necessary because of how database drivers work.
So there are variations.... In your case, the WebAPI looks like the application layer, while the code you posted looks like the service layer.