HTTP GET was initially defined to "Please transfer a named document back." [1]. The idea of interpreting the path to dynamically generate a document came later. If you like, you can think of it as a shift from Apache-circa-1999 servers that expect to deal primarily in files, to Rails-style servers that primarily route requests to dynamic code.
You're right that design patterns like Facade are often used instead of exploiting messaging. But this comes at a price: clients are necessarily aware that they are talking to a Facade. Discovery and negotiation are done statically, via the type checker. Versioning is static too. Everything it tightly coupled.
Say you have a String, and you want to concatenate it with another String. You check the docs, or StackOverflow, or IntelliSense, right? What you don't do is use Reflection to list all the methods, and pick based on their name. And you certainly don't feed an input to each method, and pick the one that gives the right output! (This strategy is routine in Smalltalk! [2])
Now say you want to build a web search engine. Do you try to statically build up website descriptions? Maybe you check StackOverflow for the HN link structure, catalog it for everyone? No, you start at the root, interrogate it, and build the link graph as you go. You have a conversation with the remote site, and perform discovery dynamically.
That's messaging! And that's why URLs are a better example than most modern programming languages: the value of OO is best realized when you have loosely coupled components, like on the Internet. (Alan Kay wrote that every object should have a URL. [3])
[1] http://www.w3.org/History/19921103-hypertext/hypertext/WWW/P...
[2] http://wiki.squeak.org/squeak/1916
[3] https://ivanovivan.wordpress.com/2010/09/13/alan-kay-quotes/