That's not the same layer. HTTP versioning is on the transport level.

All that the author is going to achieve is to have broken client codes every time he's going to bump his API version because most developers won't bother to check the content-type. Or he has control of both the client and server code and then in that case it doesn't matter.

N.B.: yes it's the same layer. HTTP is at the Application layer in the Internet layer model (and this is the Internet, not your school's Network class where they dream about OSI layers).

It's irrelevant which layer this is happening at. The point is that there is a resource address and a resource version. Decoupling those allows you to retain the same resource address for different resource versions - whether this is done for backwards compatibility, multi-language support or other reasons.

"All that the author is going to achieve is to have broken client codes every time he's going to bump his API version because most developers won't bother to check the content-type."

The point of the article was in fact to teach those mediocre developers who "won't bother", to actually bother to understand these concepts.

HTTP versioning is part of the HTTP protocol which is at the Application Layer in both the Internet Layer Model and the OSI Layer Model.

Educate yourself: http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

> Wouldn't it be nicer if the browser could tell the server which version of the interface it understands?

It would be nice! However, many packages people want to develop clients for REST APIs with have terrible HTTP support, such as Flash. If you ever see an API that supports a "method" parameter in the URL or POST body, it's because Flash is terrible.

Depending on what your requirements are, you may not need to support every outdated HTTP library in existence.