{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiefnzb5sl7brv2nmguluky2hxec7r4lvcyc3gme6eclbmhlgyxl6e",
    "uri": "at://did:plc:wvbzyoyqr6q5pgezutm4sf3v/app.bsky.feed.post/3mmzio2vmlu42"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreieoxcldglwex7qktrgi7ojrrlnbrkctystv7zh5b5l5zbikpor7pm"
    },
    "mimeType": "image/png",
    "size": 1995
  },
  "path": "/s/g9u6b7/how_do_you_version_public_web_apis",
  "publishedAt": "2026-05-29T05:44:56.000Z",
  "site": "https://lobste.rs",
  "tags": [
    "api",
    "ask"
  ],
  "textContent": "Often there is an existing API called something like \"Product API\". It often also has /api/v1 in the path.\n\nTo me this often feels like an antipattern, especially when the API itself uses semantic versioning: mixing the routes with the API contract.\n\nHaving /v1/ in the URL while also having a major.minor.patch version: coupling the first number of the semantic version to the URL path feels counter intuitive to me, if you make a breaking change, you may need new paths and new reverse proxy routes, and whatnot, and you also spread the API contract to two places, the URL and the version number.\n\nIf you start simultaneously building a brand new successor to the \"Product API\", the old API is effectively stuck as \"v1\", even if it gets breaking changes of its own.\n\nWhat do you think?\n\nDo you have any API design pet peeves or opinions to share?\n\nSorry for the confusing brain dump text, very interested in hearing people's opinions.\n\nThank you",
  "title": "How do you version public web APIs?"
}