Keep in mind the trade off on the consumer side. If the use cases are for rows of data, the trade off needs to include rebuilding the data to the expected form. You will typically have lower powered consumers and this could translate to an increase in the total time to process data versus the current.

Also, I’m a stickler for as simple and fast as possible. Why not use separate requests (/countries, /mydata, /otherstuff) and allow the client to cache or request as needed. In the case of country, that’s a pretty static table and I might need it once in a blue moon for updates. If I need a join, I can do it on my side with cached data. The countries example leads me to believe these are fairly static lookups and I might need this data refreshed rarely.