Some related reading: REST especially Gestalt; The Bees and the Ants.
As mentioned in the introduction, the Web is designed to create the large-scale effect of a shared information space that scales well and behaves predictably. Information spaces make large collections of information managable in two ways: persistence and addressability. In a library, each book has its own title, and the contents never change. In a computer filesystem, each file has its own name, and the changing of contents is carefully controlled. The web, in general, behaves like this.
Communication on the web should occur within the information space abstraction. Each unit of the space has its own address (a URI) and a corresponding network protocol for interacting with it. The conventional operations on a web addressable unit of information (commonly just called a "web page") match those on files: read the contents, read the metadata, modify the contents, delete it.
This shared-information abstraction is both restrictive and liberating, compared to the more general notion of communication as message-passing. Here, the outer meaning of a message is always restricted to a few options, like "replace the information at address X with contents Y". This architecture matches shared-memory and shared-database systems, but not remote-procedure-call (RPC) ones. The application-specific semantics of the communication act must be expressed as part of the information content, rather than in some message-operation field.
The HTTP POST operation, which is sometimes used for RPC-like operations, is intended to match a file-creation operation. The data sent on a post should be considered to be new persistent data, with its own URI assigned by the agent which receives the POST. That agent may choose to discard the information immediately, or store it privately, but conceptually the POST operation constitutes a request for a new page, with the corresponding semantics that the POSTing author asserts whatever that POSTed page says. Clicking "SUBMIT" on a web form is thus seen as making a statement, although the degree commitment and seriousness behind it, as well as its language of interpretation, must depend on context.
We recognize that web-based applications designers may not have thought in these terms, but the views are essentially compatible and giving the posted information its own URI allows for continued leveraging of the web's features. In particular, complex web service messages which require signing and where business practices require keeping transaction elements for some time naturally fit into having the POSTed messages be persistent information on the web.
If object-oriented design is used to develop an area of information space, that area will typically have a one-to-one mapping between web pages and the objects being modeled. This makes it tempting to use the URI for the web page (a collection of information) as the URI for the object being modeled, but with the increasing presence of metadata, such reuse causes problems. In particular, the semantics of an operation on a web page about another web page must be kept clear in the protocol design. The URI given in an HTTP operation must be the URI of the web page, the collection of information, not the URI of some other thing which is modeled, described, defined, or controlled by that information.