Ruminating on SemVer

Semantic Versioning (aka SemVer) of components has become mainstream today. The official page laying out the guidelines is available here - http://semver.org/

Following SemVer, each component has a 3 digit version in the format of 'Major.Minor.Patch' - for e.g. 2.3.23

• You increment the major version, when you make incompatible changes. 
• You increment the minor version, when you make changes but those changes are backward compatible.
• The patch digit is incremented when you just make a bug-fix and it is obviously backward compatible.
• With SemVer, pre-releases can be defined by appending a hyphen and the word 'alpha/beta' after it. For e.g. a pre-release for version 3.0.0 could be 3.0.0-alpha.1. 

Following SemVer is a boon in managing dependencies between components. So if component A is using version 4.2.3 of component B, then you know that as long as version B does not become 5.x.y, there would be no breaking changes. You can specify dependencies in the manifest file of a component.

While using SemVer for software components is fine, does it make sense to have the x.y.z version in the URL of public APIs?
APIs are the interfaces you expose to your consumers. Do your consumers really need to know about the bug fixes you have made? or the new features you have added? Maybe yes or no !
IMHO, just using a single version number in your API URL would suffice majority of real life business usecases. For e.g. https://api.company.com/v1/customer.

A good blog post by APIGEE on API versioning is available here. As stated in the blog - "Never release an API without a version and make the version mandatory."

If you want to constrain the amount of information that you want back from the API (e.g. mobile client on slow networks), then you can follow this strategy. Another alternative is to look at new options such as GraphQL.