Gaia lite batch endpoint for validator signing info

[faboweb]

Summary

We need to query the signing info for ever validator. This means several requests which takes a while. Let's add a batch endpoint as you usually will want to query all the info at once.

Proposal:
/slashing/validators/signing_info or /slashing/validators

Problem Definition

Proposal

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[jackzampolin]

Great idea @faboweb!

[faboweb]

This currently is 100 requests when we open the validators page.
Same goes for displaying rewards per validator. (also 100 requests)

[sabau]

I will like to have the first one as we have other routes that share that prefix

[faboweb]

but then it conflicts with /slashing/validators/{validator address}. just saying

[faboweb]

Upvote. This is really annoying in production.

[cwgoes]

@faboweb I presume you want just bonded validators, not all validators?

[alexanderbez]

@sabau @fedekunze any interest in picking this up? Good intro into the REST client.

[faboweb]

@faboweb I presume you want just bonded validators, not all validators?

does it make it difference?

[sabau]

I agree, it conflict with the current route. I think some routes hasn't been pre-designed so it's easy to fall in this now.
Currently there is a single route in slashing, so we can just forget about signing_info but I think we should re-think our routing a bit to allow this kind or requests easily.

Either having a keyword that says all but it's hacky and if we validate addresses or other parameters it won't work easily, we have to add conditions for that all around.

Usually I would like instead to push variables as close to the end as possible to avoid those cases, as when you do when you use the CLI.
/slashing/validators/{validatorPubKey}/signing_info -> /slashing/validators/signing_info/{validatorPubKey}

Or in distribution for example in:
/distribution/delegators/{delegatorAddr}/rewards -> /distribution/delegators/rewards/{delegatorAddr}
/distribution/delegators/{delegatorAddr}/rewards/{validatorAddr} -> /distribution/delegators/rewards/{delegatorAddr}/{validatorAddr}

Of course this need discussion and can't be done in this PR

[alexanderbez]

Interesting proposal @sabau. I agree with some of those routes, but we should also keep in mind they should be grouped by (REST) resource.

e.g. /distribution/delegators/{delegatorAddr}/rewards. This reads to me as "for a given delegator from all delegators, give me the delagator's rewards".

[sabau]

Regarding that it's true if you see the delegator as resource and the reward as detail of that.
I was imagining to see the list of rewards as list or resources and a particular delegator as single resource. Let's continue on the issue context (rewards list is not even a nice / useful example probably :) )