Mark Baker wrote:
> David,
>
> On Mon, Sep 19, 2005 at 08:17:06AM -0600, David Forslund wrote:
> > If the interface is the same how do I know if one is asking getAge or
> > getInvoice?
>
> You (as a client) know because you might have previously received a
> document which included some information which told you what it was,
> or described it in some way which made you want to dereference it
> (a search spider is the degenerate form of this type of client - it
> dereferences all URIs independent of the context for that URI). For
> example, within whatever ML you might be using, you might see something
> like this;
>
> <Invoice href="http://example.org/lkasjfdlkadjfsdf"/>
>
> ... which says, in the semantics of the ML in which its expressed,
> "That's an invoice". GET on it then has obvious meaning.
>
> >What about other operations besides
> > get and set?
>
> For the most part, POST fills those needs, where the client simply
> submits a document (no operation included) to a URI. For example,
> ordering something can be achieved by POSTing an order document to a
> order processor identified by some URI.
>
> As above, you might learn that via some XML like;
>
> <OrderProcessor href="http://example.org/wieruojasdfias"/>
>
> There *are* some operations which don't fit into this model very well,
> and some of those may be general enough to motivate new HTTP operations
> (e.g. WebDAV's COPY and MOVE). But in my (extensive) experience with
> Web based integration, I've only ever had to stray from
> GET/PUT/POST/DELETE, or use operation tunneling over POST, on three
> occasions (out of 100s, possibly 1000s, of deployed interfaces).
How do you specify what this integration is in REST, so that it can be
reused over and over again
without having to have your code.
My request is to do something like the equivalent of a workflow service
using REST. Use any
of the WfMC specifications in WS or IDL. Map them to to a specification
that can be automatically
run in REST. I may be dense, but if I can take a machine specification
and generate the relevant
code to run, then I could compare the various approaches better. I
don't see how interoperability
is supported without something like this.
>
> >What about "Find all individuals with a last name that
> > sounds like this name?" This type of question
> > needs to be encoded in the payload. If you send this message to my
> > server that only knows "age" (based on some
> > earlier context or "state"?), it can't intelligently respond to the
> > question. One needs to have a way to "register" the
> > server's capabilities as to what it can respond intelligently to.
>
> Exactly right. That's the role played by form languages. Note that, in
> your example, the only pure operation is "find"; everything else is just
> a description of an abstraction ("individuals with a last name
> that sounds like $foo"). That means you could map the request to a
> URI using a query form - perhaps something like this;
>
> <SoundsLikeNameQuery href="http://example.org/iuuiuiuiuiu";>
> <Param name="name" type="http://example.org/type/lastName";>
> </SoundsLikeNameQuery>
>
> A client using that form could construct a URI;
>
> http://example.org/iuuiuiuiuiu?name="forslund";
>
> .. and GET on that would give you your answer.
This seem to be great, but where did this come from? What is the
standard for doing this that everyone
would know ahead of time? The approach we have used has been around for
10 years and is quite stable.
Who would own the term: "SoundsLikeNameQuery" above? What you have is
seems to be exactly
what is required to make a RPC-like call in http/REST. What about when
the data that needs
to be sent is in binary? I guess I convert it to ascii with base64, but
this all seems overly complex
compared to using standard method calls remotely. In addition, in your
above example there is a specific path (URI) present
which keeps this from being a nice abstraction of the service that is
being requested. There must be some other
way to write what you have above because it would take hand editing
everytime I deployed the service to a different location.
>
> With more complex queries that don't serialize into URIs nicely, you may
> need to use POST though. That's not RESTful IMO (Roy Fielding disagrees
> with me), but you don't need the operation "find", you just need, as
> above, to post the data - the last name - to the right resource ala;
>
> <SoundsLikeNameProcessor href="http://example.org/jierewre"/>
>
> To fully answer your excellent question would take a while though, as
> we'd have to dig into REST's "hypermedia as engine of application state"
> constraint, and explain its value relative to the alternatives (such as
> a separate query application protocol or HTTP extension). And that's
> not to suggest that alternative approaches aren't useful in some
> cases, but just to say that a purely RESTful approach does exist.
I've never doubted that pure RESTful solutions exist. It is just that
it seems to be of similar complexity
and equivalent to other ways of solving the problem.
>
> > Certainly a registered API is one way to do this. Other
> > ways must be substantially equivalent to this and save nothing in terms
> > of implementation or deployment, since code
> > equivalent to the API must be embedded in the server.
>
> Respectfully, I don't think that's a very useful way to look at the
> difference. If you looked at it in architectural terms, you'd be
> able to evaluate the architectural properties lost and gained from the
> adoption or rejection of known constraints, and evaluate the resulting
> properties for suitability of deployment in the target environment
> (e.g. the Internet). An typical Web services approach, for example,
> rejects API constraints, and therefore sacrifices - compared to an
> equivalent Web based approach - significant simplicity, scalability, and
> reliability.
I may not be following your point here. We have deployed non-web
applications on the internet for almost 10 years
without any problems. Interoperability has worked well. The
middleware deals with most of the issues you indicate
without my having to deal with it other than make my application do what
it has contracted to do. If you have some
people writing client code (in whatever language, Java, XML, HTML, ...)
it is architecturally very helpful to have an
interface to code to so that a server and client can work correctly even
though they are developed independently by different
people and organizations. This is true regardless of what transport
mechanisms are being used. The WSDL spec attempts
to do this but not in a very portable or interoperable manner.
Something equivalent to WSDL is needed in REST, I submit. Your
above form example seems to me to be this equivalent.
Dave
>
> Cheers,
>
> Mark.
> --
> Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
> Coactus; Web-inspired integration strategies http://www.coactus.com
>
>
------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
