Except that if you understand the web you understand that a URL is worthless. Worse than worthless its down right dangerous. The moment you write a URL is the moment the clock starts ticking on the data that it refers to being the same data as the URL describes. This can fail in spectacular ways. A loooong time ago there was a web site that hosted comments on a golf courses that referenced to a hosted community site. The front side of the application would put a snippet of the comment and a link to the full comment. The service passed away into the web zombie land (the web site was still serving pages, the links still pointed at the comment site, and nobody was home). The comment site got sold or acquired and someone put up malware on every single inlink. Blammo armed and dangerous.
The concept the OP is going for is 'deferred work' which is to say not to pass around data that isn't going to be used. And that is indeed a noble goal, but you must have a way to vet that the pointer you passed still points to the thing you thought it did, or you will find out what so many C programmers have discovered about caching pointers, bad bad bad idea.
The central issue here is trust. If you trust the provider of the url to maintain the link, ensure that it stays alive and pointed to what you expect, then it's fine.
In the C caching pointers case, the issue is that the system makes no guarantees about the "live"-ness of any prior pointers, whereas on the web this is entirely possible and encouraged (See oft-cited post about "Cool URIs don't change)
The central issue here is trust. If you trust the provider of the url to maintain the link, ensure that it stays alive and pointed to what you expect, then it's fine.
How can that ever be a realistic expectation over anything but the immediate and short term? Not to mention that in the overwhelming majority of cases the "provider" of a URL is not the party responsible for maintaining it.
I have to agree with the parent - unless the recipient of the URL [continuously] validates the source, she is simply asking for trouble down the road.
I don't think I trust any web site in that regard, though. I could even see Google yanking the floor out from under me as a consumer of one of their URL schema.
If you didn't trust any web site, you wouldn't click on any link.
Trusting a website doesn't mean you have to trust them indefinitely. You can trust that the URL will be kept alive for a certain length of time - minutes, hours, days, etc - and deal with them accordingly.
The fact that you can't treat an URL as static doesn't make it "worthless", that's ridiculous.
If you want long term storage, you can always GET the content and store it locally. But if you only get a copy of the data, you can't do everything else (PUT back updated data, poll for changes, etc).
A loooong time ago there was a web site that hosted comments (...) The comment site got sold or acquired and someone put up malware on every single inlink. Blammo armed and dangerous.
And for all you know you can get malware from a data copy as well. Using URLs is not a reason to disregard basic security practices, like verifying the content that you receive from the other service.
The concept the OP is going for is 'deferred work' which is to say not to pass around data that isn't going to be used. And that is indeed a noble goal, but you must have a way to vet that the pointer you passed still points to the thing you thought it did
Which you have: the documentation says the URLs are valid for 4 hours.
I think the point being made here is only valid when you just move the data around and don't alter it. filepicker is a perfect example where you pass the data around without actually touching it and such a usage is a perfect case for passing the "pointers" around. In most other cases, you'd want to pull it down the moment you are going to transform it.
Even if you're going to pull it down, passing an URL around is still better. It means the client software can schedule the download for a few minutes or even hours to reduce peak bandwidth demands, they can PUT an updated version back, they can poll for changes, etc.
