Call Web API created in appian using integration in the same application.

This is technically possible.
If you had a genuine use case for this, then I'd suggest using a "connected system" object to manager authentication, and track users with a parameter.

That said, if you were on my team, I'd ask for a design review to understand why you proposed this pattern, and felt that you couldn't otherwise achieve your goal within Appian some other way.  Essentially, it's almost never necessary, on a single server, to use an Appian Integration to Call an Appian Web API. 
(If you want to get two different Appian instances talking, this might be a suitable approach, but that's not this use case)

Probably don't do this.
I've argued this down a number of times.
The design pattern you're proposing adds avoidable network traffic and potential points of technical failure due to the network travel.

I like to use my Appian as a House metaphor here:

Say you're at home with a friend.
You're in the kitchen and your friend is in the adjoining dining room.
You want to talk to your friend.
Would you rather:

1. walk out the back door, walk around to the front of the house, walk up the steps to the front door, ring the doorbell, wait for an answer, announce yourself, wait to be invited in, walk in, walk to the dining room, and then start talking your friend?
   
   OR
   
   
2. walk into the dining room and start talking to your friend?

(Unless you're trying to meet your daily fitbit steps goal, I suspect we'd agree that option 2 is preferable.)

So... our project management is telling us that we need to install some sort of inter-application abstraction layer between different applications on the same environment, such that they could potentially query data from each other, yet be completely independent from each other in a dependency hierarchy sense (such that any or all applications could be deployed, in any order, without being blocked by another application not being present in the environment).  This means that if App A needs to query some data from App B, it's not sufficient to just use B's query rule within objects of A. 

Also, the idea here is that no app should assume that another app is even on the same environment, or even in Appian.  This pretty much rules out Option 2 from your scenario, as we don't necessarily know our friend's location (but we do know their phone number).

Thus far, some other Appian pros in our team's orbit have been telling me that Web APIs and Integrations are the perfect solution for this -- however in the dev environment I'm currently working in, I can't get an integration to successfully query even the simplest nugget of data from an internal Web API, regardless of how I try to authenticate it or anything.

So... our project management is telling us that we need to install some sort of inter-application abstraction layer between different applications on the same environment, such that they could potentially query data from each other, yet be completely independent from each other in a dependency hierarchy sense (such that any or all applications could be deployed, in any order, without being blocked by another application not being present in the environment).  This means that if App A needs to query some data from App B, it's not sufficient to just use B's query rule within objects of A. 

Also, the idea here is that no app should assume that another app is even on the same environment, or even in Appian.  This pretty much rules out Option 2 from your scenario, as we don't necessarily know our friend's location (but we do know their phone number).

Thus far, some other Appian pros in our team's orbit have been telling me that Web APIs and Integrations are the perfect solution for this -- however in the dev environment I'm currently working in, I can't get an integration to successfully query even the simplest nugget of data from an internal Web API, regardless of how I try to authenticate it or anything.