Hacker News Reader

Comment by calfuris | Hacker News Reader

It seems like you're arguing on the wrong side of the is-ought divide. It doesn't matter how URLs should be structured, HN has to decide how to deal with how they are in fact structured by whatever site is being linked. HN exists to share articles, not to try to enforce a preferred URL structure, so making direct links impossible on sites that use a "non-preferred" structure is throwing the baby out with the bathwater. It would also be kind of hypocritical, considering that HN itself relies on query parameters to show everything but the front page.

View on HN

It does matter how URLs should be structured as that defines and constrains the text that is accepted by the designated input element otherwise without such any plain text translatable to a resource would be acceptable thus the need for rules to determine valid URLs.

> HN exists to share articles

Not to argue one way or another for that claim, but assuming it were true then enforcing a no query param constraint would allow greater visibility for the shared content as again it would prevent the specified case(s) of allowing it to get buried by submissions duplicating the link. Also, it seems pointless to go against the REST standard of using path params to identify a specific resource or resources while using query parameters to sort/filter those resources; disallowing direct linking to a filter does not make direct links to articles impossible. It is true that HN itself relies on query parameters to link resources that goes against the stated REST standard.

You're talking about duplicate discussions, but if HN trims query parameters then how can it tell if a submission to a site that relies on query parameters is a duplicate? Every URL on such sites would become identical, making different pages appear to be duplicates. That would dramatically hurt the visibility of such sites, unless HN turned off the automatic duplicate prevention for those sites, in which case the situation would be worse than the current situation.

The second half of your comment is again on the wrong side of the is/ought divide. Websites that (a) have content worth sharing and (b) use query parameters to identify a specific resource do in fact exist. The question is not whether those websites should be doing that, it is whether HN should make it impossible to link to specific resources on those websites or not.

HN as is does not reliably detect duplicates even with query parameters untrimmed; see the point above about ?id=123&comments=1 and ?comments=t&id=123. Further, even if there was an exact match on the query params in a certain order, the REST standard makes no guarantee on what resource(s) are returned on subsequent identical calls such as when an addition is added with ?topic=Conjecture or ?topic=Theorem as they are by design meant to indicate the uses like filtering or sorting. So, it's not possible to rely on identical uniform resource locators with query params to detect duplicate resources. It would be an incentive for those sites that want to be able to have more frequent visibility of specific resources on aggregator sites with duplicate detection to conform to the standard. Note detection != blocking. Those non-conforming are not being forced to change and it could be argued that visibility would be enhanced by preventing ambiguity of discussion on specific resources. If the title is set as required at the time of submission, then that field could be different and as discussed above any set of relevant URLs with query params could be added to the text field to specify resource(s) on a non-conforming site to bypass a duplicate check along with a [suggested not required] helpful description of what was seen at any query param URL at the time of submission. Obviously, the resources at non-query param URLs may change too depending on the whims of a site owner, but are suppose to be unigue resource IDs by REST.

Reply on news.ycombinator.com