If there's anything "GeoWeb" folks understand about REST, it's that REST is "lightweight". While it's possible to achieve goals simply in a RESTful system, lightness is your agenda, not REST's. Check out Roy Fielding's re-enumeration of the constraints you have to follow to get all the good properties of REST in "REST APIs must be hypertext driven". That's about as "lite" as an apprenticeship at Shaolin Temple.
On the other hand, I'm appreciating Steve Vinoski's view on RESTful HTTP as a disruptive technology in IEEE Internet Computing:
RESTful HTTP, on the other hand, has all the makings of a disruptive technology to the RPC market. As RPC systems [ed: Sun RPC and Apollo NCS, DCE, Corba, RMI, J2EE, SOAP, and WS-*] moved up-market and gained capabilities and features over time to continue to satisfy the most demanding customers, they overshot more and more potential users who shunned the complexity and cost of such systems. In RESTful HTTP, which was born in the adjacent market of the World Wide Web and is a sustaining technology there, these overshot users are finding an approach that helps them build solutions that are less expensive, simpler to build, and easier to extend and maintain than what RPC approaches can offer. It's precisely these qualities that make RESTful HTTP a disruptive technology in this context.
It's possible to do things simply using HTTP, without much REST constraint. This is the "lightweight" approach understood by the geospatial community as the "GeoWeb". The reason RESTful HTTP is disruptive is because it addresses the needs of the high end market as well. Systems applying the REST constraints can scale massively and can evolve to meet changing requirements, and that's why I'm uncomfortable with REST being pitched as "lite". Lets you achieve simple goals simply, but not itself a simple thing – is this too wonky a notion to get across?