-
Notifications
You must be signed in to change notification settings - Fork 631
[CO-334] Implement remaining V0 endpoints to V1 #3197
Conversation
-- The redemption datatypes differ only by the backup phrase. Otherwise the | ||
-- wallet ID and seed are both present. Potentially we can unify these into the | ||
-- same endpoint. Seems like a query parameter like `paper_vend_passphrase=...` | ||
-- would do nicely. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. I see no point for two endpoints here. I'd rather unify them and have a switch kind of parameter to target the right behavior. Perhaps it's not even needed and we can, at parsing-time, identify which structure is being passed and pick the right behavior after that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that, I am not sure this redeem
should be in the internal part of the API. We probably want to have them in the public-facing part?
-- -> m CTx | ||
-- data CPaperVendWalletRedeem = CPaperVendWalletRedeem | ||
-- { pvWalletId :: !CAccountId | ||
-- , pvSeed :: !Text -- TODO: newtype! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes please!
Note (wasn't maybe really clear from the requirements). What we use to call |
I agree in principle. The way I see it, there are two subtle faces of the same coin, as the original spirit of that I think that in principle though unifying everything into only one category make sense, although I'm not sure how this would work in practice: for example (if I recall correctly) we do not even expose certain dev endpoints if the |
@adinapoli-iohk Yes, and this has still the same meaning / behavior although we will also expose the documentation for these endpoints somewhere. These |
02a9a80
to
5ff10f7
Compare
Finalized 'Internal' API
|
Note that I've also re-organized commits to get a nice log-graph and easily follow the development tasks here.
|
Nice job with the commit history @KtorZ :) I'll get this merged once CI passes. |
e37c5d7
to
86b4f5d
Compare
Previously, we were going to keep the redemption endpoints in an internal section. We decided that they fit naturally into the accounts endpoints, so we moved them there instead.
…c newtypes instead.
86b4f5d
to
03fb291
Compare
CI was green, but something was merged to develop conflicting in |
- Remove the old 'Development' modules and group them together with the new 'Internal' - Remove unused endpoints ('dump-wallet-state' and 'fail') - Review module organization and put 'Internal' one level up, at the same level than V0 and V1, rather than being under V1 - Remove the 'Development' server and always expose 'Internal' endpoints. Note that the 'reset-wallet-state' will only work in debug mode (flag '--debug') with the CLI
03fb291
to
538f44b
Compare
Everything is green, no conflicts, GOTTA GO FAST |
…-v0-endpoints [CO-334] Implement remaining V0 endpoints to V1
…hk/Squad1/CO-334/implement-v0-endpoints [CO-334] Implement remaining V0 endpoints to V1
Description
This topic branch tracks the implementation of the last few V0 endpoints in V1, under a special
daedalus
namespace.Linked issue
https://iohk.myjetbrains.com/youtrack/issue/CO-334
Type of change
Developer checklist
Testing checklist
QA Steps
Screenshots (if available)