This is a draft article that describes how Water adheres to the REST architecture
for building Web applications.

REST is an architectural style for how a well-designed Web application uses
URI/URL's for representing remote resources.
Water is a new general-purpose, dynamic language for building 
Web services and applications using XML.

People say that REST is just an architectural style, and you will not
see a REST toolkit, but Water actually enforces the use of a REST-like
architecture.  Just as object-oriented programming is a style of programming
that is better supported in some languages, Water strongly supports the
REST architectural style.

Water adheres to the following REST characteristics:
o HTTP and SMTP for standardized remote application protocols
o URI/URL's for identifying remote Web resources
o XML/XHTML/GIF/JPEG representation for resource values using standard MIME types.
o Response document will embed remote references that can be chosen.
o Stateless: no stored context is required on the application server
o Cache: responses can be labeled as cacheable or non-cacheable
o Uniform interface: all resources are accessed with a generic interface
  Standard URI's can only represent a GET request.  A Water identifier 
  can represent the body string and method_types of GET, POST, PUT, DELETE
o Named resources: remote resources are named using a URL
o Interconnected resource representations: URI's interconnect multiple resources
o Layered components: intermediaries, such as proxy servers, cache servers,
  gateways, etc, can be inserted between clients and resources to support 
  performance, security, etc.
o Allows for the independent evolution of clients, servers, and intermediaries
o Client-Server: a pull-based interaction style
  Possible to have a local application server embedded in a web page.
  Client can have a server for push-based interaction style
o Design to reveal data gradually, but there might be good reasons to
  reveal more than one level.  The depth should be a parameter.

It should be noted that the SOAP and UDDI standards do not follow these principles and
that significantly increases the complexity and reduces the usefulness of those
standards.

The Water language was not influenced by the REST architecture, yet it
happens to share many of the same principles as REST.
Water extends some of the characteristics of the REST architecture
because Water looks at the Web as a set of resources to easily use.

o Water integrates a Object-Oriented security model into the core
  of the language.  This security model is known as the Capability 
  Security Model.  Security through obscurity is equivalent to no
  real security.  We should assume that every possible
  URI is known to attackers.  Design a system so that only specific 
  URI's are allowed.

o Water extends URI's and XML to general-purpose programming
  and therefore represents all implementation details as well as the 
  interface.

o Water uses ConciseXML for resource values.  
  ConciseXML offers a good solution to the long standing element vs. 
  attribute problem.  ConciseXML is compatible with XML 1.0, but fixes
  many of the problems with XML 1.0 including verbosity and ambiguity.

o The presence of a query string in a URI indicates that a 'call' is made.
  A call either creates an instance or invokes a method.  If the result
  is a value that is accessible from the server's root object, then 
  the URI is changed to show the path to that object.

o Resources may be nouns or verbs.  Verbs are method objects.  
  Returning a verb/method to the client will show a Web form for 
  calling the verb.  Nouns are objects.  Calling an object 
  will create an instance of the object.
  Resources ARE objects.

o A Water expression has a one-to-one mapping to a URI.
  A URI is a first-class object that is a name for a remote resource.
  A URI instance can include a body_string as well as the HTTP method.
  The file extension indicates the format for the returned value.
  If 'foo' is an object, the 'foo.htm' shows 'foo' as HTML, 'foo.txt'
  shows 'foo' as plain text.  'foo.gif' shows 'foo' as an image.

o Water uses Water Type and Water Contract for describing the 
  structure of some object.  This avoids the use of complicated DTD, 
  W3C Schema, RelaxNG, and Schematron.

o Referencing instances
  A URI following the REST architecture might look like:
  http://www.parts-depot.com/parts/00345

  Water would instead use the following:
  http://www.parts-depot.com/part/of/00345

  Why? The 'part' represents a class of object.  A class is generally
  never the plural form.  The '00345' represents a primary key 
  that references a particular instance of a class.
  By Water convention, instances may be stored in the 'of' field of a class.

o REST says that all resources accessible via HTTP GET should be side-effect free.
  This is a reasonable guideline, but I would argue that a URI with
  a query-string is equivalent to calling a method.  Calling a method
  may have a side-effect.  
  For example, the following URI's call the 'set' method and 
  'remove' method -- both of which are side-effecting.
  http://localhost/order/of/9911/set?quantity=10
  http://localhost/person/of/102/remove?

The new book titled Water: Simplified Web Services and XML Programming
has 43 chapters, each describing some Water Solution.  Nine chapters
are relevant to the REST architecture.

Chapters:
1 - Introduction to Pure Web Service Programming
2 - ConciseXML Syntax and XML 1.0
3 - Water Object: Representing Objects in XML
4 - Water Type: Water Type: Creating Custom Types - XSD
5 - Water Contract: Water Contract: Specifying APIs - DTD and Schemas
10 - Water Identifier and URI: Naming Resources
12 - Water Web: Accessing Remote Resources 
14 - Water Server: Creating Application Servers
16 - Water Registry: Listing Resources