On one level we got ID unique identifier of a resource, on another level we have URL, how to get a specific resources.
They are just different things that shouldn't be mixed.
What if tomorrow I want to get the same resource via graphql? Or in a message bus?
While this looks good on paper, in practice URLs were relatively stable in the early days of the internet and so they turned into de facto names before lots of effort was put into making URNs work. Now, we’re struggling with the issues they originally foresaw, but weren’t able to follow through with a working implementation.
(For more details, see https://danielmiessler.com/study/url-uri/ where I got much of this information)
If the ID is also a link, it is guaranteed to be globally unique (like a Relay Node ID in GraphQL).
If you want to get the same resource via GraphQL, just use the same URL-ID. In fact, the author mentioned the possibility of base64-ing the link to prevent clients from relying on its structure, which is also a common pattern with IDs in GraphQL.
The ID is the maximum cardinality of an entity (informally the smallest set of values of such entity necessary to uniquely identify it), the link is how to find the entity.
What happen if you want to deprecated your API?
There are other way to share the link of a resource,like use headers.
Then again, from a strictly practical point of view in 99.9% of the case it won't change anything, but:
1. Eventually there will be cases where it does matter, and then it will be an huge mess.
2. Why shut yourself a door only to don't read an header and obtain exactly the same information?