Web API Architecture considerations

Okay, I have some considerations about a Web API server architecture divided to layers:

• Presentation layer (PL) - API (with controllers, DI setup, etc., it communicates with BLL)
• Bussiness Logic layer (BLL) - Services (which contains bussiness logic, it communicates with DAL)
• Data access layer (DAL) - (which communicates with DB)
• database (DB)

API accept some kind of XRequest class and pass it to service, service process it and returns some kind of XResult, which API returns as response.
BLL may process it and create new object or pass it along to DAL, and DAL does not expose objects from DB, so it also returns some kind of XResult.

1. May I call these objects, that are passed through layers a Data Transfer Objects? Or DTO is reserved only for HTTP communication?
2. Where should all these objects (?DTO?) stored? I mean, all bussiness logic is in BLL, so I think that it should be defined in BLL, even for DAL. With PL and BLL communication it is good, I think, but on the other hand, I think it breaks the independency of DAL, as it returns objects defined in BLL. So it looks like this:
   PL→BLL⟷DAL
   I can place DTO responsible for BLL⟷DAL communication to DAL, and it will look like:
   PL→BLL→DAL
   But it means that DAL will be responsible in some kind for bussiness logic, I think. Nevertheless, it will be, because I want it to provide specific data with one database query, not only CRUD operations (that's also why DTO for DAL exists). Maybe should be BLL and DAL combined to one layer, lat's call it Domain layer?
3. In ASP.NET service objects and data access objects may be configured for Dependency Injection in API. But I think it also breaks the convention of layers, because the API layer defines which DAL implementation should be used. I've seen this in a lot of tutorials, but I've never seend that someone complains that. Is it ok?
4. If my API is used by web app written in other tech stack and is used as client-server architecture, may I call this web app a "View", and say that I have MVC architecture for all system? (Controller for api and controllers, model for database and logic, view for web app that uses my api)? Or should I stay with client-server? Or something else?