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

Re: [rest-discuss] REST toolkits

Expand Messages
  • Tony Butterfield
    ... Are you thinking of RDF for defining, declaring and documenting the interfaces? ... Looking at the service, there are at least three aspects: 1)
    Message 1 of 37 , Feb 9, 2004
    • 0 Attachment
      On Fri, 2004-02-06 at 15:15, Josh Sled wrote:
      > And, personally, I'd try to make it easy to exchange RDF/XML instead of
      > just XML, for many reasons.

      Are you thinking of RDF for defining, declaring and documenting the
      interfaces?

      > So what would such a toolkit look like?
      >
      > Let's start with a simple use-case to engender discussion...
      >
      > Alice provides an Image-Processing web service, with a RESTful interface.
      > Bob wants to connect to and use that service before lunch. The service is
      > pretty simple: given an image and list of transformations, it returns the
      > transformed image [plus some other things it determines along the way].
      > Ideally, Bob would like to sit down an write:
      >
      > --
      > Image img = // ...;
      > TransformList xformList = // ...;
      > ImageProcessing imgSvc = ImageProcessing.getInstance();
      >
      > Image newImage = imgSvc.processImage( img, xformList );
      > display( newImage );
      > --
      >
      > * What parts of this can the toolkit help with or make simple?
      > * What [information, description, &c.] is required to use it?
      > * Why _wouldn't_ Bob use it?
      >
      Looking at the service, there are at least three aspects:
      1) implementing the service
      2) providing a public interface to the service
      3) providing meta-data about the service

      As far as implementing the service goes, I think it would great if the
      toolkit would provide all abstractions to implement the service
      independent of the public interface, provide implementations of the
      common web datatypes and provide tools for the management of the
      service.

      As far as providing the public interface I would good to be able to
      declaratively map the service onto some public interface. I.e. lets say
      put the ImageTransformService at http://imagetools.org/transform or
      send an multipart mime email to transform@... with the image
      and the specification as attachments, or with more thought send a MMS
      (multi-media messaging) from your phone and get your fixed up image
      back!

      Providing meta-data. I'd like to explore this issue more. To use RDF or
      WSDL to describe an interface is nice but useful only for automatically
      building static client stubs or providing documentation. I haven't seen
      technology that can semantically understand an interface definition in
      its most general sense, only human interface proxies that can provide a
      better view of a service to a human.

      Looking at the client side of the scenario, It would be great for the
      toolkit to be able to leverage a service, independent of how is a made
      publicly available (functionality willing). So we could build up the
      parameters to a request using standard web datatypes- in this example
      say and XML specification plus a PNG image stream. Then pass them to the
      service. I think the important aspect is that any complex service may
      well leverage other services so it will need good support to be a client
      too!

      >
      > I guess I realize after I type this up that there may be two really different
      > goals here, between building a toolkit focused on:
      >
      > 1/ human-machine -- a toolkit for building RESTful, human-focused web sites.
      >
      > 2/ machine-machine -- a toolkit for building RESTful,
      > developer-/code-focused web services.

      > Which toolkit do you want to build? I'm looking for the latter.
      > I don't think they're entirely seperate, actually, but it's good to know
      > where we stand. :)

      The two types would certainly require different functionalities but I'd
      like to think that the commonality is the larger part. It is those "low
      level" common features that interest me.
      --
      Tony Butterfield <tab@...>
      1060 Research
    • Tyler Close
      ... I agree. ... I think I understand what you re trying to say here, but you are misusing the term coupling . I think you re saying that many processing
      Message 37 of 37 , Mar 5, 2004
      • 0 Attachment
        On Tue March 2 2004 01:22 am, Tony Butterfield wrote:
        > However IMHO there are a large number of processing problems that can
        > easily solved by scripting services (behind REST interfaces)

        I agree.

        > together into pipelines, as described by Josh, without resorting
        > to coupling your XML to objects. If you can do this you save
        > yourself a lot of work, particularly when the system evolves.

        I think I understand what you're trying to say here, but you are
        misusing the term 'coupling'.

        I think you're saying that many processing tasks can be
        accomplished without using an OOP environment, and that doing so
        can often be a good design. I agree. In fact, I designed the
        Waterken Webizer <http://www.waterken.com/dev/SQL/> based on this
        premise.

        It's interesting to note that the XML interface used by the
        Webizer is the same as that used by the XML to Java mapping. This
        property comes from the fact that the XML interface is designed to
        be loosely coupled to the AST.

        Many people seem to misunderstand what 'coupling' is. A piece of
        code, or data, is coupled to something if it uses that something.
        The coupling is 'loose' if there are many possible substitutes for
        that something. Otherwise, the coupling is tight.

        When I demonstrate an XML to Java binding for an interface, I am
        demonstrating loose coupling. The interface is loosely coupled to
        the AST used to represent it. The examples in the Waterken Message
        Tutorial <http://www.waterken.com/dev/Message/Tutorial/> show
        automated transformation between the XML AST and the Java AST.
        These ASTs have become substitutes for each other. That's loose
        coupling.

        The flipside of this argument is that not having an XML to Java
        binding is a demonstration of tight coupling. The interface is
        tightly coupled to the XML AST, because there are no substitutes
        for the XML AST.

        Taking this argument further, I claim that data represented in the
        Waterken Doc Model <http://www.waterken.com/dev/Doc/Model/> is
        more loosely coupled than the XML documents used in Josh's
        examples. This loose coupling comes from the fact that the Doc
        Model was designed to support mapping between many different ASTs.
        This makes it easy to build mappings into a wide variety of
        execution environments.

        Take a look at the grammar for the Doc Model:

        http://www.waterken.com/dev/Doc/Model/#Grammar

        Notice how simple this grammar is compared to the XML infoset,
        Java Serialization Streams, etc. This simplicity creates loose
        coupling by making it possible to represent the data using any AST
        whose grammar is a superset of the Doc Model grammar. The
        complexity of the XML infoset grammar precludes this kind of
        mapping.

        In general, I've read a lot of nonsense about 'coupling'. I hope
        this email gives people an objective basis on which to reason
        about coupling. When people claim loose coupling, ask them to list
        the available substitutes. When people accuse tight coupling, show
        them the list of available substitutes.

        Tyler


        --
        The union of REST and capability-based security.
        http://www.waterken.com/dev/Web/
      Your message has been successfully submitted and would be delivered to recipients shortly.