5 ms·

It's a shame that the author frames this "issue" in such a negative light. Remember when this used to be the most valuable feature of the Web? Remember "The U

It's a shame that the author frames this "issue" in such a negative light. Remember when this used to be the most valuable feature of the Web? Remember "The URL is the new command line?" That was back in the the early days of Web 2.0, back when people used that term with a straight face and even a bit of optimism, and where you might also use the term "Mashup" in the same sentence. Having consistent URL formats for Posts, Users, Dishwasher Models and everything else made it so that you could pull information out of web pages quickly and easily without the need for a formal API. It was a pretty cool time to be writing software because you could quickly suck in data from tons of places in ways that they hadn't specifically anticipated. But it died just as fast as it rose because of SEO. Over the span of a single year, everybody had to change their urls to look like http://site.org/blog/learn-rails-in-20-minutes http://site.org/blog/learn-rails-in-20-minutes and suddenly you couldn't do anything useful with them again. Shame. But yeah, at least whatever edge case this author talks about isn't there anymore. To mitigate that, I'd recommend Jason's Law of the Internet: "Try to avoid putting things on the Internet that you don't want to be on the Internet. That way there won't be anything you put on the Internet that you didn't want to be there."

vidarh 11y ago
When I did Edgeio, we did what you describe. While we had human readable slugs, there was an item id at the start of every url, and if you stripped off or changed the rest, you just got the same page but with a <link ...> back to the canonical version. We also built the entire thing basically as an API that just happened to by default pass through a processing step to render HTML. If you gave the right argument, you'd get the page back as our own XML markup [1], RSS or ATOM instead. We didn't go full HATEOAS [1] (didn't exist yet), but we there was a decent amount of descriptive links etc. pointing the way in the XML/RSS/ATOM versions. [1] That was actually what the web app generated; it was converted server side using XSL, but if you "flipped the right switch" it'd serve up the XML with an XSL stylesheet and it mostly worked fine that way in most browsers, though we never invested the resources in making it flawless (but it was a great debugging tool to get the raw XML served up straight to the browser... everyone came out hating XSL though, for good reasons) [2] https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS
geerlingguy 11y ago
I'm fine with IDs in URLs (either redirected to a pretty URL or not); I'm suggesting that you simply make sure that unpublished content doesn't get redirected to the pretty URL so you can avoid this kind of information leakage.

vidarh 11y ago

When I did Edgeio, we did what you describe. While we had human readable slugs, there was an item id at the start of every url, and if you stripped off or changed the rest, you just got the same page but with a <link ...> back to the canonical version. We also built the entire thing basically as an API that just happened to by default pass through a processing step to render HTML. If you gave the right argument, you'd get the page back as our own XML markup [1], RSS or ATOM instead. We didn't go full HATEOAS [1] (didn't exist yet), but we there was a decent amount of descriptive links etc. pointing the way in the XML/RSS/ATOM versions. [1] That was actually what the web app generated; it was converted server side using XSL, but if you "flipped the right switch" it'd serve up the XML with an XSL stylesheet and it mostly worked fine that way in most browsers, though we never invested the resources in making it flawless (but it was a great debugging tool to get the raw XML served up straight to the browser... everyone came out hating XSL though, for good reasons) [2] https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS

geerlingguy 11y ago

I'm fine with IDs in URLs (either redirected to a pretty URL or not); I'm suggesting that you simply make sure that unpublished content doesn't get redirected to the pretty URL so you can avoid this kind of information leakage.