API routes design proposal to allow batch requests

[sabau]

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}

Originally posted by @sabau in #3226 (comment)

[sabau]

I would propose not to do that before we split the repositories but this may come with some benefit:

• increase a bit the power to represent single items VS list of items all over, with no special cases
• same logic as CLI,

[alexanderbez]

Thanks @sabau! See my comment here: #3226 (comment). I think there are defintely places where we can improve our routing as you've suggested. But we should strive to maintain the RESTful nature of the endpoints too :)

[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.

But also with this reasoning we can't cover 100% cases

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.