-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add wallet address to subresource requests #305
Conversation
🦋 Changeset detectedLatest commit: 0f67aaf The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
✅ Deploy Preview for openpayments-preview ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Still need to add a changeset before this will be marked ready for review. |
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.
What do you think about always using the walletAddress
in the query params, both in the GETs and the POSTs? To keep it consistent?
In any case, we should make wallet address always required + update the client package
Do we need to support RESTful clients? I think those don't allow for query params in POSTs. |
e026da9
to
64b56e5
Compare
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.
Do we need to support RESTful clients? I think those don't allow for query params in POSTs.
I wouldn't say that having query params in POST is necessarily not RESTful, but I wasn't sure of the tradeoff between the weirdness of that vs needing to pass in the walletAddress
differently depending on the method. We can just go with the more standard approach of no query params, was just curious to hear thoughts
Also, for the usage of the client, we can actually abstract that away by having it take in walletAddress
as it's own parameter and do what we need to do internally in the client depending on the method:
client.incomingPayment.get({ url: '<some URL for the RS>', walletAddress: '<walletAddress>'...}) // uses wallet address in query params
client.incomingPayment.create({ url: '<some URL for the RS>', walletAddress: '<walletAddress', accessToken: '' }, { expiresAt: ... }) // uses wallet address in request body
openapi/resource-server.yaml
Outdated
examples: | ||
Complete incoming payment for https://openpayments.guide/alice: | ||
value: | ||
walletAddress: 'https://openpayments.guide/alice/' |
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.
maybe this can just be the ilp.money
wallet address one will be good so it works with Blair's PR regardless who merges first
@@ -334,6 +339,9 @@ paths: | |||
schema: | |||
type: object | |||
properties: | |||
walletAddress: |
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.
POST /quote request body should also contain walletAddress
Yeah, I'm thinking the no query parameters in POST will work. If someone asks "why did they do it this way?", then it may be a stronger argument to point to that dogma than a personal preference for consistency |
d5fc764
to
34c6a68
Compare
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.
LGTM, not sure if this should be merged before or after #307, however
AuthenticatedRequestArgs {} | ||
|
||
export interface CollectionRequestArgs extends AuthenticatedRequestArgs { | ||
export interface ResourceOrCollectionRequestArgs |
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.
Just a thought I had, should we change the name of the url
argument to be instead resourceServerUrl
for the POST requests (since we end up appending the resource name, e.g. /incoming-payment), to be more clear that we will be appending the resource name during those requests?
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 think that can be part of Adrian's PR
Right now, wallet address and all other resources are part of the same spec with the same server url. As soon as wallet address moves to its own spec, this makes sense.
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.
Sorry, this 👆was supposed to be a comment to you question below.
Do we need to return the |
I think #305 (comment) also covers this. I think this version of Open Payments doesn't need to account for resource servers differing from the wallet address until Adrian's PR. Just need to make sure it's captured in an issue or in the scope of that draft PR |
34c6a68
to
e860b72
Compare
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.
One small little thing
openapi/resource-server.yaml
Outdated
@@ -650,6 +671,7 @@ paths: | |||
description: A client can fetch the latest state of an incoming payment to determine the amount received into the wallet address. | |||
parameters: | |||
- $ref: '#/components/parameters/id' | |||
- $ref: '#/components/parameters/wallet-address' |
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 don't think the wallet address is needed here because the id is unique.
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.
Is it also the case for completing an incoming payment (https://github.com/interledger/open-payments/pull/305/files#diff-9debc2038853698222051b2c2a428cee93e9dda6af6076de559971933879580dR722-R725) since the path still contains that unique id?
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, indeed.
openapi/resource-server.yaml
Outdated
@@ -748,6 +785,7 @@ paths: | |||
- $ref: '#/components/parameters/signature' | |||
parameters: | |||
- $ref: '#/components/parameters/id' | |||
- $ref: '#/components/parameters/wallet-address' |
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.
Same here
0f4d8af
to
8b42dfc
Compare
8b42dfc
to
0f67aaf
Compare
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.
LGTM
Changes proposed in this pull request
POST /outgoing-payments
POST /incoming-payments
POST /incoming-payments/{id}/complete
GET /incoming-payments/{id}
GET /outgoing-payments/{id}
GET /incoming-payments
GET /outgoing-payments
Context
Fixes #304.