4 ms·

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

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." [1] https://news.ycombinator.com/item?id=29009729 https://news.ycombinator.com/item?id=29009729 [2] https://news.ycombinator.com/item?id=21560626 https://news.ycombinator.com/item?id=21560626 [3] https://news.ycombinator.com/item?id=29014181 https://news.ycombinator.com/item?id=29014181 [4] https://www.w3.org/DesignIssues/Axioms.html https://www.w3.org/DesignIssues/Axioms.html

dane-pgp 5y ago
> "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." [0] https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIRefer... [1] https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/making-api-requests.html https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIRefer...
- rektide 5y ago
  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.

dane-pgp 5y ago

> "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." [0] https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIRefer... [1] https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/making-api-requests.html https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIRefer...

rektide 5y ago
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.