I'm pretty sure they mean "API" in its true sense. An API for a module or a library, not necessarily a Web API. It's not unusual for an organization to maintain several projects/libraries/services that interact internally via their APIs (sometimes over HTTP, sometimes directly as a library), SemVer makes perfect sense for this use case.
They mean API in the sense of anything that someone can declare a dependency against.
Whether it's a web service or a library is immaterial; the point of the thing is to be able to update something and formally tell any downstream dependencies whether the update breaks compatibility or not.
Re:Semantic Versioning 2.0.0 (2013)
by SimonPStevens on Sunday August 27, 2017 @02:28AM
(#15109425)
Yeah, which is fine if that's what you do. You can take 'public' to have whatever meaning works for you.
I'm talking about places that try and apply SemVer to their consumer facing product, that has no API. That doesn't make sense.
> 1. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.
SemVer doesn't even make sense if you don't have a public API. SemVer doesn't make sense for end user products that don't have an API. I really wish people would stop trying to abuse it.