Loading ...
Sorry, an error occurred while loading the content.

"Extreme Web Services"

Expand Messages
  • Paul Prescod
    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
    Message 1 of 7 , May 3, 2002
    • 0 Attachment
      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.
    • Dan Brickley
      [snip] minor nitpick: the UUID vs URI characterisation is a bit bogus, since there is (or could be -- forget the status) an easy way of writing UUID
      Message 2 of 7 , May 4, 2002
      • 0 Attachment
        [snip]

        minor nitpick: the UUID vs URI characterisation is a bit bogus, since
        there is (or could be -- forget the status) an easy way of writing UUID
        identifiers in URI syntax. You might say that URIs are good, but some
        kinds of URI are more good than others... ;-)

        Dan


        --
        mailto:danbri@...
        http://www.w3.org/People/DanBri/
      • Matt Gushee
        ... IIRC it is urn:uuid:rqio502u82qy8ervthkgnxiyw349$&*%()&*%$&*$^((%^&(*asdjoaw -- Matt Gushee Englewood, Colorado, USA mgushee@havenrock.com
        Message 3 of 7 , May 4, 2002
        • 0 Attachment
          On Sat, May 04, 2002 at 03:19:20PM -0400, Dan Brickley wrote:
          >
          > minor nitpick: the UUID vs URI characterisation is a bit bogus, since
          > there is (or could be -- forget the status) an easy way of writing UUID
          > identifiers in URI syntax.

          IIRC it is

          urn:uuid:rqio502u82qy8ervthkgnxiyw349$&*%()&*%$&*$^((%^&(*asdjoaw

          --
          Matt Gushee
          Englewood, Colorado, USA
          mgushee@...
          http://www.havenrock.com/
        • Sam Ruby
          ... http://www.globecom.net/ietf/draft/draft-kindel-uuid-uri-00.html - Sam Ruby
          Message 4 of 7 , May 4, 2002
          • 0 Attachment
            Dan Brickley wrote:
            >
            > minor nitpick: the UUID vs URI characterisation is a bit bogus, since
            > there is (or could be -- forget the status) an easy way of writing UUID
            > identifiers in URI syntax.

            http://www.globecom.net/ietf/draft/draft-kindel-uuid-uri-00.html

            - Sam Ruby
          • Paul Prescod
            Yes, excellent point! I really mean resolvable URIs which at one time were termed URLs . I gues you could establish a hierarchy of goodness: names -
            Message 5 of 7 , May 6, 2002
            • 0 Attachment
              Yes, excellent point! I really mean "resolvable URIs" which at one time
              were termed "URLs". I gues you could establish a hierarchy of goodness:
              names -> universal names -> universally resolvable names.

              Dan Brickley wrote:
              >
              > [snip]
              >
              > minor nitpick: the UUID vs URI characterisation is a bit bogus, since
              > there is (or could be -- forget the status) an easy way of writing UUID
              > identifiers in URI syntax. You might say that URIs are good, but some
              > kinds of URI are more good than others... ;-)
              >
              > Dan
              >
              > --
              > mailto:danbri@...
              > http://www.w3.org/People/DanBri/
            • Mark Baker
              ... Wait a minute! DDDS will make URNs resolvable. Should we call them URLs now too. 8-) MB -- Mark Baker, Chief Science Officer, Planetfred, Inc.
              Message 6 of 7 , May 6, 2002
              • 0 Attachment
                On Mon, May 06, 2002 at 12:43:19PM -0700, Paul Prescod wrote:
                > Yes, excellent point! I really mean "resolvable URIs" which at one time
                > were termed "URLs". I gues you could establish a hierarchy of goodness:
                > names -> universal names -> universally resolvable names.

                Wait a minute! DDDS will make URNs resolvable. Should we call them
                URLs now too. 8-)

                <ducks/>

                MB
                --
                Mark Baker, Chief Science Officer, Planetfred, Inc.
                Ottawa, Ontario, CANADA. mbaker@...
                http://www.markbaker.ca http://www.planetfred.com
              • tony_hammond@harcourt.com
                We call them URIs. :) Tony Mark Baker rg cc: Dan Brickley ,
                Message 7 of 7 , May 7, 2002
                • 0 Attachment
                  We call them URIs. :)

                  Tony





                  Mark Baker
                  <distobj@acm.o To: Paul Prescod <paul@...>
                  rg> cc: Dan Brickley <danbri@...>, "rest-discuss@yahoogroups.com"
                  <rest-discuss@yahoogroups.com>
                  06/05/2002 Subject: Re: [rest-discuss] "Extreme Web Services"
                  21:41






                  On Mon, May 06, 2002 at 12:43:19PM -0700, Paul Prescod wrote:
                  > Yes, excellent point! I really mean "resolvable URIs" which at one time
                  > were termed "URLs". I gues you could establish a hierarchy of goodness:
                  > names -> universal names -> universally resolvable names.

                  Wait a minute! DDDS will make URNs resolvable. Should we call them
                  URLs now too. 8-)

                  <ducks/>

                  MB
                  --
                  Mark Baker, Chief Science Officer, Planetfred, Inc.
                  Ottawa, Ontario, CANADA. mbaker@...
                  http://www.markbaker.ca http://www.planetfred.com


                  To unsubscribe from this group, send an email to:
                  rest-discuss-unsubscribe@yahoogroups.com



                  Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                Your message has been successfully submitted and would be delivered to recipients shortly.