Too many fields in the responses

[wilsonsilva]

This is something I need to consider if it is worth changing or not. Loqate's responses are flat and contain many fields. I could group those fields and create smaller objects, but then the end user would need to refer to Loqate's documentation as well as the gem's documentation in order to figure out what to do.

[Darhazer]

My two cents on this:

If I have to choose one or the other, I'd stay with 1:1 mapping with the Loqate API, as it's easier for the developer to refer just one documentation.
But why not eat your case and have it at the same time?
You can provide the smaller objects for a better API, while still preserving the original fields.
So you add a country object to the detailed address, that helps the name and various ISO formats, or a contact to the bank account validation, that holds the contact_ posts, but allow those to be accessed directly as well.

Than you can educate your users about those cleaner interfaces, by the means of deprecations or even custom rubocop rules (that would even support auto-correction!). So you enable people to quickly onboard with the lib, by following just one documentation, but then make their code more elegant, by having cleaner objects and dealing only with the subsets of data they care about.

What do you think?