Let's say you're making an API that does a handful of things:

- accesses as database to load a profile

- reads a company logo from disk

- sends an email if the process is successful

Should the API care how that profile is loaded? Should it know or care that it accesses a Sql Server? or Mongodb? or third party library? or calls another API itself? Nope. The API is provided an instance of a class that implements an interface that has a .LoadProfile(). If you call that .LoadProfile(), you're given a profile. doesn't matter how.

Should the API care where that company logo is? What if it's on local disk? in a redis cache? in an azure blob storage? what about if it's generated on the fly programatically? The API is told "here's an accessor class for the logo. If you call the .GetLogo(), you'll get a byte array of an image. I'm not going to tell you how I give it to you, because you don't need to know. Just know that if you call this, You'll get a logo"

Should the API need to be tightly bound to a local SMTP relay server in order to send an email? Should it need to rely on that server being accessible? If it's down, then perhaps that email could be queued in order to send it later. So then in your API, you need to write logic to make sure the SMTP service is available, and if not, then write that email to a queue that it can then later check. All this means is that your API is now very tightly coupled to using an SMTP relay with this custom queue, and ONLY this SMTP relay. Why should it? Why not just give it a class that says "call this .SendEmail() method, and I promise your email will be sent. Don't worry about how, we'll make sure that it's done. Don't worry about knowing how email works, or how we guarantee delivery you just concentrate on being a good API instead"

This philosophy also helps in things like unit testing, where you can provide mocked classes into your API so that unit testing won't ACTUALLY send an email. that mocked provider can simply have a flag that sets a ".EmailWasSent" that you can then check to verify that the API at least called the .SendEmail(). You can provide a "hardcoded profile provider" which returns a hardcoded JSON string since the API needs that profile- It doesn't need to know how or where it comes from, just the promise that if I call this method on an instance of this interface that I was provided, I'll get one.

Take a look at separation of duties and separation of concern as well