Web agents interoperate to jointly form the web by using one or more of the web's network communication protocols. These protocols are distinguished from protocols in general by their use of URIs as persistent identifiers. This use is intended to create the abstraction of an information space, a collection of information which is made more manageable by being divided into smaller, individually addressable collections.
Information spaces have a long history of proven utility [Bees&Ants]. One of the most familiar examples is scientific literature, where the normal unit of addressing is the published article. The interwoven citations of the literature helped inspire the web's original design. Another example is the computer filesystem, where information is divided into files, each identified by an (absolute path) filename. A great deal of web content is stored in computer files mapped directly to the web.
For addressability to work, allowing one to point to a particular information unit as having particular qualities and enabling users to navigate the space, the information content of each addressable unit must be somewhat persistent or consistent across varying conditions. If the content changes randomly, nothing meaningful can be said about the unit and its address becomes useless. (@@@ heaby overlap with earlier URI persistence discussion.)
In the web, the units of information space are commonly called "web pages". Each one has its own information content; taken together they comprise the vast information content of the web. Maintaining each individual collection (page) is the responsibility of one or more agents acting as servers. This distribution of pages across agents allows the web to scale well and to spread across administrative boundaries.
Agents also act as clients, gaining access to pages using web protocols to communicate with the servers. The URI for each page includes information identifying a protocol, as well as the necessary information to use within that protocol to contact the server and obtain a representation of the page. Use of the encoded scheme is not manditory, as there may be other ways for a client to access the page information (such as by consulting a cache using a different protocol), but it provides a primary method.
The methods for accessing an information store can vary, but in HTTP and FTP they closely match filesystem operations. [ A web protocol modeled on database operations, including transactions, might be interesting. Or do e-tags and webDAV do that? Check it out. ] These operations are: read and write the data (HTTP GET and PUT), read the metadata (HTTP HEAD), remove this unit (HTTP DELETE), and add a new unit (HTTP POST).
While the web is intended to support communication indirectly, with information travelling via addressable storage areas (web pages), the more direct message-passing approach can be effectively and productively incorporated by recognizing that the contents of a message are often stored for a time by the message receiver.
...
A common view of HTTP POST is that it provides a mechanism for clients to send messages to servers, while its original purpose (as above) was more in the file-creation vein. The posting operation was intended to allow for new information to be made available on the server, much like a new file. These two views are compatible, however, if we view the posted information (a message) as something to which the server MAY store and assign a URI.
This view matches written communication, where messages are passed via persistent and identifiable media, such as peices of paper. The receiver of some written correspondence is generally entitled to keep it for some time and in some cases even to publish it. W3C archived mailing lists turn potentially transient messages into proper web content by assigning them URIs and assuming responsability as web servers for those URIs. Web bases bulletin board systems often do the same using messages sent via HTTP POST.
The architectural point here is subtle but important: if messages are assigned suitable URIs they become units in the web's information space and get all the benefits of linking and the web's infrastructure. Systems which have a reason to keep the information in a message they receive SHOULD assign it a URI and be a server for it if privacy mechanisms are in place (appropriate for context of the message).
For example, when a user presses "BUY NOW" to finalize a purchase, the seller will (for business reasons) need to maintain a record of that transaction. ...
As a more complex example, ...
In object-orient design, an information system is developed by identifying and characterizing the different classes of things (conceptual or physical "objects") about which information is to be handled. Object-oriented programming systems provide mechanisms for the information about each member or instance of a class to be tightly clustered, with the selection of stored information depending on the class.
oo information systems help manage complexity by placing all the information about each modeled thing into a corresponding addressable unit and providing access through class-specific mechanisms. OOIS are information-space systems with two extra qualities:
1. the unit division is based on an OOD. This arrangement happens [lukily] on the web sometimes, when a web page has a single subject and is the sole source of information about that subject.
2. the access mechanism is class specific.
The REST model has (1) but not (2); SOAP has both.
...