A discussion on API versioning practices, questioning the coupling of URL paths (e.g., /v1/) with semantic versioning and exploring potential antipatterns.
<p>Often there is an existing API called something like "Product API". It often also has /api/v1 in the path.</p>
<p>To me this often feels like an antipattern, especially when the API itself uses semantic versioning: mixing the routes with the API contract.</p>
<p>Having /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.</p>
<p>If 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.</p>
<p>What do you think?</p>
<p>Do you have any API design pet peeves or opinions to share?</p>
<p>Sorry for the confusing brain dump text, very interested in hearing people's opinions.</p>
<p>Thank you</p>
# How do you version public web APIs?
Source: [https://lobste.rs/s/g9u6b7/how_do_you_version_public_web_apis](https://lobste.rs/s/g9u6b7/how_do_you_version_public_web_apis)
Often there is an existing API called something like "Product API"\. It often also has /api/v1 in the path\.
To me this often feels like an antipattern, especially when the API itself uses semantic versioning: mixing the routes with the API contract\.
Having /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\.
If 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\.
What do you think?
Do you have any API design pet peeves or opinions to share?
Sorry for the confusing brain dump text, very interested in hearing people's opinions\.
Thank you
The article examines the pitfalls of altering API behavior depending on the linked SDK version, using Windows' CoInitializeSecurity as a case study. It discusses issues with DLL version mismatches and tail call optimization that complicate this approach.
A discussion on how developers handle credentials for coding agents, exploring an approach where agents use APIs without receiving raw secrets, with injection at request time and destination restrictions. The author is building this as part of Stashbase and invites others to share their practices.
Engineering notes comparing three approaches to unifying access to multiple LLM providers (OpenAI, Anthropic, Google) behind a single internal interface, discussing trade-offs in API normalization, native SDK usage, and gateway patterns.
This article exposes a pattern where major platforms like X, Reddit, and Stack Overflow train AI models on user-generated content for free, then charge exorbitant API fees for access to that same data, and ban users who protest or delete their content.