Oh snap. There was a pretty broad dismissal of URLs making real inroads in the world in the recent Roy Fielding's Misappropriated ReST Dissertation[1]. Everyone seemed to agree that this core, fundamental part of HATEOS was basically dead, unloved, & going no-where, was my read.
I mentioned Marcel Weiher (@mpweiher) In-process ReST[2] in that thread[3], and admitted indeed this is something we don't see a lot of. But I personally think it's enormously worth doing. Rather than having entities implicitly be of some entity, merely floating identifiers, I think there's enormous value in having infrastructure & systems that refer to each other the same way clients refer to information... via urls, as real resources.
Which is what Tim Bray got Lambdas doing, way back when. And it's paying off well. Tim Bray, trying to cite Tim Berners-Lee, pulled this choice quote:
> "On the Web, a resource is a unit of information or service."
Tim's doing a good job talking to a lot of hopes I still have. If anyone's curious for more, I cannot recommend enough TimBL's "URIs - Axioms of Web Architecture"[4], which is still the only sensible basis I've heard for online information. Thanks for this incredibly timely share @HB.
> "Any resource anywhere can be given a URI" "Any resource of significance should be given a URI."
has indeed flowed well into Tim Bray's conclusion:
> "But to be honest, all of that comes more or less for free once you decide that everything you might want to integrate is a resource and thus should be identified by a Uniform Resource Identifier. I recommend this design pattern."
> "On the Web, a resource is a unit of information or service."
Does the inclusion of "service" mean it is logical for an API to accept different "actions" as query parameters of the same resource?
AWS has API actions such as "GetMetricData"[0] and the documentation[1] helpfully says:
"CloudWatch does not care which HTTP verb you use in a request. POST requests, GET requests, PUT requests, DELETE requests and so on all return the same result."
Making each method it's own resource is a kind of interesting challenge. I'd vastly prefer to see individual metric data resources exposed as such- each with their own url- or with range urls- instead of passing a generic DAO endpoint a payload requesting some metrics. But at some point I am sympathetic to the query simply being too verbose to handle.
Microsoft's OData was an interesting walking the line act. It was a fairly genuine attempt to make a webful, url-ish way of querying for data. Part of me still thinks it was a great idea part of me thinks it's not in the least different from GetMetricData, even though it's generic, even though it's urlish and rangeful; it's still not passing some sniff tests.
Since it looks like this got put into the second chance queue and there's still not much discussion, here are various musings about URIs:
- First, I don't think this post makes a very compelling case for URIs. I'm not mad it was written, or that I read it twice, I just think it says very little. I think the plea from last year's "Please make your products work with URLs" post is a lot more compelling <https://news.ycombinator.com/item?id=22038065>.
- I want mail servers to use URLs (or URL-looking things, to pre-empt the sticklers in the crowd) for MIME Message-IDs, esp. for "public" messages like mailing list posts, newsletters, or any kind of email that includes any kind of "view this message on the Foocorp website" link. Or, at the very least, I want tighter integration between mail servers and web servers so I can trivially resolve a message over the Web. E.g. if your mail server allows messages signed @example.com to be sent and it's generating something like <3eac99e6-943e-6cea-a336-1797d8dc0578@example.com> for the Message-ID, then I want to be be able to put https://example.com/3eac99e6-943e-6cea-a336-1797d8dc0578 into my browser's address bar. It's okay if you initially return a 401/403 and require me to authenticate out-of-band if the content is not sufficiently public, but this should still be possible. (You don't actually have to make the content live at https://example.com/3eac99e6-943e-6cea-a336-1797d8dc0578 for the canonical URL; return a 3xx and point to the right place.)
- For URLs in particular, I wish more people realized that the relationship between URLs and content does not have to be one-to-one. You can have an unlimited number of names that resolve (via 3xx redirection) to the same resource. Likewise, if you're part of an organization and you find yourself moving things around out of a compulsion to "tidy up" the content hierarchy, but you don't have the power (or wherewithal) to install rules on the Web server to keep the old URLs working (e.g. because the server just uses a dumb files-and-directories-to-content mapping), then please stop.
- When you set up a new laptop or desktop and are prompted to name your machine, you can use that name judiciously. If Alice controls example.net and her laptop is named citrus-micrantha, then she can identify files as <file://citrus-micranthia.example.net/home/alice/Documents/thesis.pdf>. It doesn't even matter that citrus-micranthia.example.net isn't resolvable by software outside the context where she uses that name, e.g. because there are no routes set up on any network-facing equipment. (Note that in Firefox, at least, if you do try to "resolve" these identifiers, they'll actually work, so long as you're doing so on the machine where the file actually lives.)
> I want mail servers to use URLs (or URL-looking things, to pre-empt the sticklers in the crowd) for MIME Message-IDs, esp. for "public" messages like mailing list posts, newsletters, or any kind of email that includes any kind of "view this message on the Foocorp website" link. Or, at the very least, I want tighter integration between mail servers and web servers so I can trivially resolve a message over the Web. E.g. if your mail server allows messages signed @example.com to be sent and it's generating something like <3eac99e6-943e-6cea-a336-1797d8dc0578@example.com> for the Message-ID, then I want to be be able to put https://example.com/3eac99e6-943e-6cea-a336-1797d8dc0578 into my browser's address bar. It's okay if you initially return a 401/403 and require me to authenticate out-of-band if the content is not sufficiently public, but this should still be possible. (You don't actually have to make the content live at https://example.com/3eac99e6-943e-6cea-a336-1797d8dc0578 for the canonical URL; return a 3xx and point to the right place.)
No, what JMAP is doing and what I described are two totally different things. My proposal centers on URIs and Fielding-style REST that requires no special knowledge of the server implementation or even media type. JMAP is straight up FIOH-style[1] "REST", requiring out-of-band information on both.
I mentioned Marcel Weiher (@mpweiher) In-process ReST[2] in that thread[3], and admitted indeed this is something we don't see a lot of. But I personally think it's enormously worth doing. Rather than having entities implicitly be of some entity, merely floating identifiers, I think there's enormous value in having infrastructure & systems that refer to each other the same way clients refer to information... via urls, as real resources.
Which is what Tim Bray got Lambdas doing, way back when. And it's paying off well. Tim Bray, trying to cite Tim Berners-Lee, pulled this choice quote:
> "On the Web, a resource is a unit of information or service."
Tim's doing a good job talking to a lot of hopes I still have. If anyone's curious for more, I cannot recommend enough TimBL's "URIs - Axioms of Web Architecture"[4], which is still the only sensible basis I've heard for online information. Thanks for this incredibly timely share @HB.
> "Any resource anywhere can be given a URI" "Any resource of significance should be given a URI."
has indeed flowed well into Tim Bray's conclusion:
> "But to be honest, all of that comes more or less for free once you decide that everything you might want to integrate is a resource and thus should be identified by a Uniform Resource Identifier. I recommend this design pattern."
[1] https://news.ycombinator.com/item?id=29009729
[2] https://news.ycombinator.com/item?id=21560626
[3] https://news.ycombinator.com/item?id=29014181
[4] https://www.w3.org/DesignIssues/Axioms.html