Change governance REST endpoints to a more REST-ful structure

[faboweb]

Proposal for rest-ful structure:

submit: POST /gov/proposals
deposit: POST /gov/proposals/{proposalID}/deposits
vote: POST /gov/proposals/{proposalID}/votes
get votes for address: GET /gov/proposals/{proposalID}/votes?address={voterAddress}
read proposal: GET /gov/proposals/{proposalID}
get proposals an address voted for: GET /gov/proposals/?voted={voterAddress}
get proposals by creator: GET /gov/proposals/?proposer={proposerAddress}

build endpoints returning tx that are signed client side (for later):
GET /gov/proposals/build
GET /gov/proposals/{proposalID}/deposits/build
GET /gov/proposals/{proposalID}/votes/build

[sunnya97]

I currently don't keep track of the proposer of a proposal. Is this something desired?

[faboweb]

Situation: The great dictator sunny wants to track all his proposals like "give 66% of atoms to sunny" or "let us make everyday a taco Tuesday" but he doesn't want to scroll through all the unimportant proposals. Then we would need this.
How much of an overhead would it be to store the proposer?

[sunnya97]

@faboweb Given that the vote/deposit msg being POSTed contains the proposalID, is the idea to have it do a safety check, that the msg.ProposalID is the same as the one in the rest endpoint?

Also, why are addresses params while proposalIDs are REST paths?

[sunnya97]

Regarding storing the proposer, I feel like we don't want to create a model in which we associate proposals with their proposer. How about we have one for all the deposits done by a specific address? Deposits feel like more of a "anyone can become a partial owner of the proposal", not just a single person.

[faboweb]

The arguments posted to the endpoint should not equal the constructed msg I think. Therefore the body in the POST does not contain the proposalID. The ID is taken from the URL.
Is a safety check necessary?

For query vs path params:
Path params are IDs selecting from the parent ressource. Query params select on other properties. In this case we are not selecting by voteID but by a property of the vote (voter).

Is that understandable?

This is all to create a consistent API structure.

[faboweb]

For proposerid:
Is there a downside to storing the ID?
I am not feeling strongly about it though.

[faboweb]

On 2nd thought: Maybe let's change the votes endpoint to /gov/proposals/proposalID/voters/voterID What do you think? Sunny Aggarwal <[email protected]> schrieb am Fr., 22. Juni 2018, 16:05:

…

Regarding storing the proposer, I feel like we don't want to create a model in which we associate proposals with their proposer. How about we have one for all the deposits done by a specific address? Deposits feel like more of a "anyone can become a partial owner of the proposer", not just a single person. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1284 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFmO2bU1FwKtarkTUJ_zCPksrZ2sBNhDks5t_U4GgaJpZM4UqVeb> .

[sunnya97]

voterID == address?

[faboweb]

Yes! :) Sunny Aggarwal <[email protected]> schrieb am So., 24. Juni 2018, 03:32:

…

And voterID is the address? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1284 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFmO2e8f522YAHU0srrBqWlkf3nSqERLks5t_uwUgaJpZM4UqVeb> .

[sunnya97]

@faboweb Changing scope of this issue. Moving

build endpoints returning tx that are signed client side (for later):
GET /gov/proposals/build
GET /gov/proposals/{proposalID}/deposits/build
GET /gov/proposals/{proposalID}/votes/build

to a new issue (#1356). So it can be done after #1355 first.

[sunnya97]

@faboweb @adrianbrink
Thinking about it, I feel URL parameters for POSTs are kind of weird. I think it makes sense for GETs, but for POST, I would prefer to just post the tx/msg as a whole. Thoughts?

[faboweb]

A huge benefit of doing parameters in POSTs is, that you can track what is going on in the network history.
The bigger benefit I guess is to abstract messages away from the app developers. So the interface always stays the same for the app developer. The light client on the other hand can change the message format reflecting the current state. This results in less frustration and less time updating code to newer SDK versions.