This is probably the 5th time I come back to this discussion and reading it all from the original question to the last response. And every time I have this feeling that (perhaps because of how the question was stated) there is some weird mix of “domain design” and “implementation details” concerns.
So this time I’ll try to approach it differently. I’ll start by removing the “noise” from the original question and extract the business need. That seems to be
to retrieve read only data from somewhere
I’d argue that all the API, REST, service, … concerns are implementation details. The domain design challenge would be exactly the same if we were talking about common database or common file system.
I’d start by identifying the following
How important is that data for individual components? How accurate and up-to-date it must be? That will determine your data access policy. Perhaps it’s OK to request it every time, perhaps not. It may be that some components need to keep local copies (for performance or reliability reasons). It may be that some components can not or should not operate unless the data is up-to-date (whatever that means in business terms).
How reliable / performant the access to the data must be? How the system reacts to outages and latency? Perhaps it’s not a concern at all. Perhaps it’s so crucial that there must be more than one channel to access the data and a respective fallback strategy in place. Perhaps it differs for different components.
Who is the owner of that data, the access channels to it and what is the relationship with the owner of the system? In other words, what is the cost of change? Perhaps it’s the same owner and all will always evolve together. Perhaps there has to be some sort of contract between them and changes are agreed. Perhaps one side must account for any unexpected changes?
Answering those will IMHO give you a rather good idea of what the viable data access strategies are. It can be REST API, it can be DB access, it can file system, it can be any combination of the those and many more with or without caching.
As for when to access the data, that’s easy - when you need it! It could be a command handler if the command processing logic needs it. It could be event handler if it’s event processing logic that needs it. It could be service, repository, projection or any component, given that you know its expectations, assumptions, constraints and you’ve prepared the adequate data access strategy for that component.
Finally to reflect the topic question - I don’t think it’s “architecturally wrong” to call a REST API from Command/Event Handlers. It’s certainly no more wrong than executing a SQL query or reading a file from a file system. That said, all of those have consequences one should be aware of.
Just my 2 cents.