*sighs* the neovim to catgirl pipeline claims another promising young man

True, but it seems safer to instead just ride easier trails.

Every class can also be considered a form of API. Each layer of your application (ORM, client, service, controller) should prune down what it is passed to only what it explicitly needs to provide to the layer above.

Second, if your data comes from an external source, that doesn't mean you should expose everything they give you. Only expose the resource *you* intend to provide. What happens if you change vendors? Try to make every resource generic and essential.

There are two main traps that cause people to make this mistake. First, there is a tendency to just expose internal models. Don't do that. Have a well thought out data transfer object (DTO) that only passes relevant data.

YAGNI - You Ain't Gonna Need It. Don't build things (or expose data) you *think* you'll need. I've seen people complain that YAGNI is an excuse for under-engineered solutions, but it is really just optimizing flexibility for an uncertain future.

So many 'principles' of software design focus on this concept. For example, the open-closed principle. Code should be open to extension and closed to modification. You can always add properties (extension) as the business case requires, but can't remove properties.

Even for internal API's, you never know how someone is going to use your data. So you become responsible for maintaining every property regardless of whether it is relevant to the resource you're exposing. This gives you less flexibility and makes code more difficult to maintain over time.