Why use ASP.Net Web Api instead SignalR for internal project

Why not both?

You can use WebAPI to provide bulk data, and SignalR as an optional thing to provide updates in the data. So you would provide both functionalities, first REST to allow third parties consumers, and also offer a push technology like SignalR, or directly WebSockets, to allow callers to subscribe for changes in particular data sets.

Please keep in mind that SignalR is not only WebSockets, if fact, you need Windows 8 or Windows 2012 as server in order to use them. Otherwise, it will fallback to another transport that may not work as good as you think it does. Also, as Daniel pointed out, the scalability of SignalR is ... kind or limited, and even their own documentation states you should not use it for real time scenarios or very segmented data. SignalR is just for general broadcasting, I prefer go straight to WebSockets with the native Windows API if you are in Windows 8/2012 or a third party component.

If the client is always the action initiator, and the frequency of requests is irregular or not high, then probably REST request/response approach simplifies things a lot. If otherwise, the client does requests very often and/or with a constant rate, then go with a WebSocket, but you will need to work a little bit more.

SignalR is overkill in most cases for Request/Response, I would go with REST. And then use SignalR for push updates.

For push updates you can abstract SignalR with this library (Im the author) https://github.com/AndersMalmgren/SignalR.EventAggregatorProxy