Re: [rest-discuss] REST toolkits
- 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 ofAre you thinking of RDF for defining, declaring and documenting the
> just XML, for many reasons.
> So what would such a toolkit look like?Looking at the service, there are at least three aspects:
> 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?
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
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
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
>The two types would certainly require different functionalities but I'd
> 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. :)
like to think that the commonality is the larger part. It is those "low
level" common features that interest me.
Tony Butterfield <tab@...>
- On Tue March 2 2004 01:22 am, Tony Butterfield wrote:
> However IMHO there are a large number of processing problems that canI agree.
> easily solved by scripting services (behind REST interfaces)
> together into pipelines, as described by Josh, without resortingI think I understand what you're trying to say here, but you are
> to coupling your XML to objects. If you can do this you save
> yourself a lot of work, particularly when the system evolves.
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
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
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
Take a look at the grammar for the Doc Model:
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
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.
The union of REST and capability-based security.