A Lobsters thread started by user jussi on May 29, 2026, questions the common practice of embedding version numbers like /v1/ in public web API URLs. The post argues that mixing URL paths with semantic versioning creates coupling between the API contract and routing, making breaking changes harder to manage. The author suggests that when a new API version is built, the old one becomes stuck with its URL version label even if it receives its own breaking changes. The thread invites opinions on API design pet peeves and best practices.
lobsters user jussi kicked off a thread asking why everyone puts /v1/ in api urls when it makes versioning messy. they say it's an antipattern because you end up with two version numbers (url and semver) and old apis get stuck with their url label. thread is asking for hot takes on api design.
This discussion reflects an ongoing tension in API design between simplicity and long-term maintainability. As more companies expose public APIs, the choice of versioning strategy affects developer experience and system evolution. The debate highlights that even widely adopted conventions like URL path versioning can have hidden costs, especially when APIs need to evolve independently of their URL labels.
api versioning is one of those things everyone does but nobody loves. this thread shows devs are still trying to figure out the least bad way to handle breaking changes. the /v1/ convention is so common it's almost invisible, but it might be causing more problems than it solves.
Public story text does not change until an admin approves it.
Looped stories are not disposable posts: receipts, claims, reader checks, and moderator decisions can change the approved version over time.