Skip to content

Reconfigure /staking/ADDRESS to accept stash and give controller, rewardDestination#94

Merged
danforbes merged 18 commits intomasterfrom
zeke-staking-take-stash
Jun 17, 2020
Merged

Reconfigure /staking/ADDRESS to accept stash and give controller, rewardDestination#94
danforbes merged 18 commits intomasterfrom
zeke-staking-take-stash

Conversation

@emostov
Copy link
Contributor

@emostov emostov commented Jun 16, 2020

Overview

  • Delete payout/:address and move that info to '/staking' in order to create a single endpoint for an accounts staking info.
  • Start migration to a more RESTful resource model by changing endpoint paths.
  • Rudimentary error handling improvement in get

Endpoint change from staking/:address/:number to accounts/:address/staking/:number discussion

tl;dr - we should think about changing the path to accounts/:address/staking/:number because it more accurately models our resource taxonomy.

As we approach V1 and dialing in the api, the importance of communicating meaning through our endpoint increases and thus it behooves us to carefully consider how they model resources.

After offline discussion with @danforbes, consensus has begun to coalesce around modeling the resource accounts, representing the (collection of) AccountIds of the chain. Under accounts we would then have single resource, an account, identified by its AccountId, (commonly referred to in sidecar and its reference material as ADDRESS or address).

Following this we can identify the following resources and relationships to an account:

  • balance belongs to an account; an account has one balance.
  • staking{information} belongs to an account; an account has one staking{information}.
  • vesting{information} belongs to an account; an account has one vesting{information}.

Using this model we can then define paths that semantically correspond:

  • accounts/:address/balance
  • accounts/:address/staking
  • accounts/:address/vesting

If critical consensus can be reached on the aforementioned paths, it still leaves the question of where an optional number (block hash or height) parameter would semantically fit with our model. Some say REST principles lean towards using a query param because number is not necessarily a resource ID, but instead a search term. However, to another subset of people, simply putting number at the end of the path still communicates model while staying terse. These two options for number would look like:

  1. accounts/:address/staking?number=2643
  2. accounts/:address/staking/:number

To move the discussion forward, I have gone ahead and changed the staking paths to accounts/:address/staking/ and accounts/:address/staking/:number

What about the other two routes?
In order to keep the diff for this PR minimal I decided to only change this route for now. However, if this change is implemented the other routes should be changed prior to the v1 release.

Follow up PRs:

  • Creating a swagger to document API
  • Modify other endpoints to stay in line with model

save progress

Add errors and setup statusCode handling in `get`

Switch errors to throw

change routes to `accounts/:address/staking/:number`

Remove toJSON on stakingLedge; Add backslash to front of path
@emostov emostov force-pushed the zeke-staking-take-stash branch from 63b45cc to 0c86bb2 Compare June 17, 2020 01:52
danforbes and others added 2 commits June 17, 2020 10:02
Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
@danforbes danforbes merged commit 3cca1e7 into master Jun 17, 2020
@danforbes danforbes deleted the zeke-staking-take-stash branch June 17, 2020 17:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants