I have been having trouble clearly defining/specifying how a URL/URI should be applied to situations such as search queries or different resource formats. The question is what an actual "uniform resource identifier" is, and how it should be applied to complex situations involving queries and formats.
The REST paradigm (at least from my history with Ruby on Rails) made it so that you can define clean URLs that got rid of the older URL query parameter style in earlier PHP and related apps. So instead of:
/?format=html&articleId=123
It became:
/articles/123.html
This made it so (what seems like) all URLs could be expressed "RESTfully" without using the ?
. So it would be like:
/:class1/:id/:class2/:id/...
You can also get "collections" of resources like this:
/articles
That would return all the articles.
But here's where the idea of URL and REST breaks down. Typically when you return data to /articles
, it might be paginated, and might be the most recent articles.
Let's say this is Twitter and there is a constant stream of new content. Then /tweets
will constantly return something different than what was returned before. So the question is, what the actual "uniform resource" is.
It seems clear to imagine a "uniform resource" when you are talking about an individual database record, like a user record. You have a list of properties, and an ID:
id: 123
email: [email protected]
name: Example name
...
That would be accessed via /users/123
.
However, even this sort of breaks down, when you modify the user record. Say you change the email of the user:
id: 123
email: [email protected]
name: Example name
...
Now the same URL returns something different than before.
To solve this, you start to bring in the idea of versions. So it might be like this:
/users/123/v1
/users/123/v2
...
/users/123/v<hash>
But you don't really see that out in real-world apps. However, that data might be returned in an ETag or other HTTP header, so it is there somewhere, sometimes, but it's not in the URL, the "uniform resource identifier". So the URL is lacking some important uniqueness information.
Another example is with queries. Searching in Google Chome for "StackOverflow" uses this URL:
https://www.google.com/search?q=stackoverflow&oq=stackoverflow&aqs=chrome..123123.abcabc&sourceid=chrome&ie=UTF-8
There is no date or version information there, and the results are tailored to me, so the same URL will return something different for another user.
Another example is with API calls for collections. A facebook URL that provides a cursor to paginated data is closer to a good "URL":
https://graph.facebook.com/me/albums?limit=25&after=MA123123...=
That unique after
token probably goes to the database, which stored a set of IDs to use as the next query result if the API call is made, so in a sense it accurately captures the "uniqueness" in URL (unique resource identifier :p). But I'm not sure exactly how Facebook implements that, so it could still be off and not totally accurate in uniquely representing the resource (for example, maybe if new data is added in between now and the usage of that URL, it will return those new records in the result).
The definition of URI from Wikipedia says:
A Uniform Resource Identifier (URI) is a string of characters designed for unambiguous identification of resources and extensibility via the URI scheme.
However, all of the cases presented here (twitter feed, google search results, facebook api response) are ambiguous. Even the simple REST api call to /users/123
is ambiguous because of the versioning changes to the user record.
So my question is, if there is a solution to the problem of using URLs, or something like URLs, to accurately represent a unique resource. That seems like what IPFS and other blockchain technologies are partly doing, creating a unique hash from the content every time it changes (sort of like git). However, this only seems like it would work for objects, not for collections of objects, or api/search results. For that I haven't seen a solution. It is almost as if you want to accurately snapshot the state of the system at a particular time, and use that as a URL. So a search URL would look like this:
/articles?titleMatches=foo×tamp=123123
And that would return a result set like Facebook's API does, paginated. But then the after
cursor would essentially take a snapshot of the database state of all the objects at the current version they are at when that URL request was made. So the after
cursor would contain data along the lines of:
articleIdVersionHashes: [<hash1>, <hash2>, ...]
That would make the URL uniquely identify the content.
However, this would break down the meaning of the URL address bar in browsers. Typically you just want to go to https://twitter.com and see your home profile (content under the /
URL that is unique to you, or if you are logged out, the Twitter homepage). The URL bar is more of a guideline than a Unique Resource Identifier.
In all of these ways, it seems that the idea of URL is broken. Wondering if there are any solutions to this problem, or alternatives to the idea of a URL, and how to effectively think about the idea of uniquely representing a "resource" (and what a resource actually should mean).
Basically I'm wondering if there is a better way to conceptualize the URL address bar, what it's meaning and purpose is. Because the name "URL" isn't accurately describing what's happening.