interledger
Make resource collection URLs explicit
Currently the resource collection URLs that are used to create and list resources are implicit.
e.g. Given a payment pointer https://example the resource collection for creating new incoming payments is https://example/incoming-payments.
There seems to be no advantage to this given that we require a client to get a grant to access any of these URLs.
A cleaner and more extensible solution would be for the server to provide the URL of the resource collection to the client as part of the grant response.
Example: AS response for grant to create/read incoming payments
{
"access_token": {
"access": [
{
"type": "incoming-payment",
"actions": ["create", "read", "list"],
"locations":["https://example/incoming"]
}
]
}
}
From this response the client knows that it must perform create and list operations by making a POST or a GET to https://example/incoming.
Would https://resource-server-url/incoming be the standard?
Or would the RS need to register the corresponding (sub)resource urls (locations) with the AS?
https://datatracker.ietf.org/doc/html/draft-ietf-gnap-resource-servers#section-3.4
It looks like locations is intended to represent an RS, as opposed to a collection
https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol#section-8
Or would the RS need to register the corresponding (sub)resource urls (locations) with the AS?
This
It looks like locations is intended to represent an RS, as opposed to a collection
I think that the concept of an RS is less specific than you're implying. In theory it could be possible to have an entirely different RS for each resource collection. These are a perfectly valid set of RS URLs for different resource collections:
- https://payments.example.com/incoming
- https://quotes.example.com/
- https://payments.example.com/outgoing
As with all of the other URLs returned by API responses we should avoid assumptions about the authority or path relative to the API request URL.
@adrianhopebailie given we now have resourceServer and authServer as properties on the wallet address, probably less relevant? Unless you see the benefit of resource-specific URLs, although that might complicate things more.
(we are just doing some issue cleanup)
