Here is my rough counter-part to this document:

http://www.extremeprogramming.org/rules.html

I notice that Microsoft co-opted the term "extreme web services" in a
talk in February ... oh well.

1. Loose coupling of implementations: Clients should not need to know
anything about the object models of services and vice versa. It is
therefore almost never appropriate to generate an interface definition
for an extreme service from existing implementation code. The interface
should be chosen to maximize interoperability and extensibility, not to
simplify implementation.

2. No Implicit Resources: If the server has some information that it is
willing to make available to the client then that information should be
exposed as part of a URI-named resource. The client should not need to
submit XML-encoded "parameters" or a "query" to get the information.
The means for getting the URI is discussed in other points.

3. No Implicit State: If the client and server depend on a shared piece
of information in order to communicate effectively then that piece of
information should be given an address (usually by the server) and
exposed as a web resource. Clients should be considered entirely
stateless. The only thing they remember from one message to another are
things defined by the protocol, like authentication tickets -- not
things defined by the application, like purchase order numbers.

4. No abuse of protocols or formats: Knowingly violating either the
letter or the spirit of specifications degrades the value of those
specifications ot you and others. Most often if you read the
specifications you will learn that the creators anticipated your problem
and made a provision for it. If not, the chances are strong that your
problem is out of scope for the protocol or format and maybe you should
choose another one or invent your own.

5. Use standards where possible: HTTP is the standard Web protocol for
the manipulation of information. XML is the standard Web representation
for information. RDF is the standard representation for metadata. By
default, you should use these. Use something else only when you have
researched these closely and have a clear sense of a limitation of one
of these. Using something non-standard will be expensive for those
building client applications that will use your service. You should
explicitly justify that cost.

7. Use URIs (typically URLs) to name things: URIs are better names than
numbers, UUIDs or other non-standard naming conventions. The first
virtue of URIs is that they are derived from a managed namespace so name
clashes can be avoided merely by choosing only to use names that we each
own. For instance if two companies merge their purchase orders will be
uniquely named because the two companies would have formerly had unique
domain names. Whereas this is not necessarily true of integer-named
purchase orders. Second, URIs provide an easy way to associate metadata
(or "plain data") with the named entity. Even if you do not need that
today you may need it later.

8. Use hyperlinks (URIs embedded in XML or HTTP headers) to guide the
client through the service: Do not require it to build up state on the
client side. The state should be encapsulated into resources that the
client creates. As long as it keeps track of one URI, it should be
possible for it to re-discover all of the relevant state merely by
following hyperlinks. A query is only better than hyperlinks as an
optimization and when the client is likely to have a priori knowledge
that must be plugged into the service (e.g. a dress size).

9. Given the choice between a generic interface and a specific one, use
the generic one if your goal is to maximize interoperability: It may
take more effort to re-organize your information into the generic
interface but that effort will usually pay off for your clients. For
example, XML is a generic data representation and is sometimes not quite
as efficient as application-specific notations. Nevertheless it is
usually the right choice because the client can implement one XML parser
instead of hundreds of parsers for application-specific notations. The
same sort of argument can be made for HTTP.

10. Disclaimer meta-rule: the real world is complicated and there are
many broken
software products and business environments out there. Break rules when
you need to do so -- but understand the costs of breaking them and
document your reasons.