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

Sun proposes to apply Web service standardization principles to REST

Expand Messages
  • Elliotte Harold
    It had to happen sooner or later. The big boys are waking up and discovering REST, and naturally they want to protect all us little developers from worrying
    Message 1 of 53 , Feb 14 6:56 AM
    • 0 Attachment
      It had to happen sooner or later. The big boys are waking up and
      discovering REST, and naturally they want to protect all us little
      developers from worrying our pretty little heads about nasty things like
      HTTP and XML by creating easy-to-use REST frameworks:

      JSR-311 Java API for RESTful Web Services

      Remember, these are the same jokers who gave us servlets and the
      URLConnection class as well as gems like JAX-RPC and JAX-WS. They still
      seem to believe that these are actually good specs, and they are
      proposing to tunnel REST services through JAX-WS (Java API for XML Web
      Services) endpoints.

      They also seem to believe that "building RESTful Web services using the
      Java Platform is significantly more complex than building SOAP-based
      services". I don't know that this is false, but if it's true it's only
      because Sun's HTTP API were designed by architecture astronauts who
      didn't actually understand HTTP. This proposal does not seem to be
      addressing the need for a decent HTTP API on either the client or server
      side that actually follows RESTful principles instead of fighting
      against them.

      To give you an idea of the background we're dealing with here, one of
      the two people who wrote the proposal "represents Sun on the W3C XML
      Protocol and W3C WS-Addressing working groups where he is co-editor of
      the SOAP 1.2 and WS-Addressing 1.0 specifications. Marc was
      co-specification lead for JAX-WS 2.0 (the Java API for Web Services)
      developed at the JCP and has also served as Sun's technical lead and
      alternate board member at the Web Services Interoperability Organization

      The other submitter seems to be a primary instigator of the Fast Infoset
      effort to hide XML in binary goop.

      This is like asking Karl Rove and Dick Cheney to write the Democratic
      Party platform.

      Do we really want to trust these folks to define the official Java spec
      for REST? Please read the JSR, and send comments to jsr-311-comments@...

      I hope we can derail this completely, but we probably can't. If not, are
      there any JSR members here who might join the working group and bring
      some sanity and actual REST experience to the development of the
      eventual specification? If we can't stop it, maybe we can at least limit
      the damage.

      ´╗┐Elliotte Rusty Harold elharo@...
      Java I/O 2nd Edition Just Published!
    • Nic James Ferrier
      Thanks for this. It s a fantastic list! ... Surely this doesn t need to be tested? An application is not non-RESTfull if it doesn t implement a method that we
      Message 53 of 53 , Feb 18 1:45 PM
      • 0 Attachment
        Thanks for this. It's a fantastic list!

        Benjamin Carlyle <benjamincarlyle@...> writes:

        > * Every resource should implement as many of the architecture's
        > interaction patterns as makes sense. eg GET, PUT, POST, DELETE,
        > HEAD.

        Surely this doesn't need to be tested? An application is not
        non-RESTfull if it doesn't implement a method that we may think it
        should. That is subjective.

        > * Content types should
        > ** Be free from verbs (except for code-on-demand), representing pure
        > data.
        > ** Encode similar data schemas into the same document type
        > ** Be standard wherever possible
        > ** Include standard documents as sub-documents wherever appropriate
        > ** Extend standard document types through subclassing when variation is
        > required
        > ** Invent new document types when nothing out there is a good fit

        All of these seem testable to me.

        > Evolvability:
        > * Components should ignore features of a document they do not understand
        > * Components should avoid wildcard matches in parsing that might lead
        > them to interpret a feature they do not understand as if it were one
        > they do understand
        > * Components should not alter their processing depending on a version
        > number found in a document
        > * If incompatible changes occur to a document type, it should normally
        > be given a new document type identifier
        > * Components should continue to support legacy features and interface
        > until such time as it is known that they are no longer in use

        Most of these look like client side things. It has just occured to me
        that automated client testing looks very difficult.

        > Horizontal scalability:
        > * When a server does stores state due to client requests, that state is
        > either:
        > ** Hidden from view, or
        > ** Made visible as a resource that can be further retrieved and
        > manipulated
        > * Server-side state storage should be avoided when no money is changing
        > hands to support this storage. This can be said for sessions, pub/sub,
        > and other times when the server stores state either temporarily or
        > perminently. Paying for bandwidth almost involves funny money, but
        > storage can really cost you. It hurts horizontal scalability, increases
        > complexity, and generally makes life hard. That said, most services need
        > to store some state. Just don't to any more than you have to.

        I think this boils down to a question of not doing cookies or URL

        Nic Ferrier
        http://www.tapsellferrier.co.uk for all your tapsell ferrier needs
      Your message has been successfully submitted and would be delivered to recipients shortly.