HTTP, REST, and Middleware
HTTP servers are middleware servers. that's it. end of story.
well, maybe not the end.
i'm not a fan of talk about HTTP apps needing middleware; that's redundant. OOP apps need objects, right?
see "...Hypertext Transfer Protocol (HTTP) is an application-level protocol..." and, as such, is used as an abstraction layer between clients (common browsers, RIAs, desktop apps, bots, etc.) and server resources (file systems, databases, other servers, etc.).
and the REST architectural style is an excellent way to implement middleware services on HTTP servers. the defined constraints of this style include well-known ones (Client-Server, Stateless, & Cache) and ones unique to REST (Uniform Interface, Layered System, & Code-On-Demand). These, combined w/ the understanding that "...REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state." provide a rich and stable environment for building highly-scalable "...distributed, collaborative, hypermedia information systems."
see, that's what middleware does.
and that's what HTTP does.
and that's why REST is so effective.