It's also an excellent way to check for security problems, for pages which should be generated just for you. Increment/decrement the number - get someone else's information. I have reported countless instances of this with varying rewards and success; you can count on someone, somewhere making this mistake regularly.
I agree with the sentiment of the article, but not with the majority of the points the author makes.<p>Most of the time, information catalogued and then URL-ised by AUTO_INCREMENT are public information that could easily be spidered another way. As the article noted it's not hard to look back at previous job postings (using the article's example).<p>So most of the time AUTO_INCREMENT is just used as an arbitrary counter / identifier which is just as guessable with other arbitrarily chosen identifiers. The linked blog uses /CCYY/MM/ URL to order the articles, then a natural string to specify a specific record, and that method could just as easily work for the record ID in the same way /AUTO_INCREMENT/NATURAL_STRING. But the question of whether you'd want to hide (or make it harder to guess) URLs for articles published to the public still remains.<p>Where AUTO_INCREMENT really causes problems is when you have information you <i>don't</i> want public. Such as session IDs. But in those instances, it would be rare to URL-ise them in the first place (bar maybe some AJAX calls). And as far as I'm aware, nobody uses AUTO_INCREMENT for session IDs anyway (they'd have to be pretty useless developers if they did).<p>There might be some argument against AUTO_INCREMENT for some user-submitted / community services such as PasteBin and URL shorteners. But even here, if the information isn't intended to be public then it either a) be hidden behind some level of authentication or b) shouldn't have been published online to begin with.<p>Security aside, the other point he raised was with SEO. However even that's not really an issue for the same reason his /CCYY/MM/ URL isn't an issue: sites that need search engine optimised will support a human readable string as part of the URL.<p>So I don't think his "<i>Stop Putting AUTO_INCREMENT IDs in URLs</i>" is really tackling the real problems and I think his example is very misleading. The real issue is people who use predictable (which includes guessable hashes) row ID's as identifiers for non-public data <i>AND</i> the issue with developers who choose to hide non-public data behind obscurity[1] instead of secure authentication. None of which has much to do with URLs in the first place (since incrementing session ID's are just as bad regardless of whether they're encoded in a URL, HTTP "POST" body, a cookie, or whatever)<p>[1] <a href="https://en.wikipedia.org/wiki/Security_through_obscurity" rel="nofollow">https://en.wikipedia.org/wiki/Security_through_obscurity</a>
You conflate several things and construct a problem where there is none:<p>* yes, auto-incrementing session IDs are bad and downright stupid. Noone ever does this (right?).<p>* information leakage about the number of jobs per month or similar is not a problem unless you're trying to maintain some sort of illusion about your company / web page, which hopefully most people/companies won't do (they have no good reason, unless they're crooks). Nowdays archive.org will take many snapshots of web pages, so will Google and any visitor can do it, so why try to hide something obvious?<p>In general, it's not an anti-pattern: it's fine for products in online shops, properties on real estate platforms, blog entries, etc.. To avoid it there would simply mean to make URLs longer and uglier with no good reason.
on the other hand, I'm currently using quite random IDs (firebase), and the URLs are just ugly: /jobs/-J_wBsKY4Rn1WgMPB7-_/operations/-J_wBsKf4-WYh9ohK7j8