Re: Issue 169: Propose http method in the operation interface to simplify http binding.

Hi Sanjiva,

On Tue, Jul 13, 2004 at 09:56:37AM +0600, Sanjiva Weerawarana wrote:
> 
> "Mark Baker" <distobj@acm.org> writes:
> >
> > Any constrained interface you come up with will either be less general
> > than the REST interface (by definition), or equivalent to it.
> 
> :-).
> 
> So there can never be any single interface that is more general than
> the REST one? Wow.

Was that facetious?  I can't tell.  But yah, it's true because as I
said, it's by definition.  An operation is maximally general if it is
applicable to all things, which is a long-winded way of saying that it's
uniform - the same "uniform" that REST requires of its interface
semantics.

> > CRUD is
> > less general.  For example, that mapping above fails to expose POST
> > functionality which permits for things like data processing, annotation,
> > insertion, etc..
> 
> Update can do all that stuff. So can query BTW (just invoke a UDF).

Ulster Defence Force? 8-)
http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=udf&Find=Find

But presumably you mean "User defined function"?  Well, if you do that
then you're no longer doing UPDATE, you're tunneling one operation
through another, and you'd need out-of-band agreement for that; you'd
have to call the person who publishes the CRUD interface and ask "I'm
about to send you a purchase order to process through your UPDATE
operation that I want you to process as a purchase order, ok?".
Otherwise they just think you're trying to update when you invoke the,
erm, update operation. 8-)

> > > I don't know what "GET on mailto:foo@bar.com" means because I don't have
> a binding.
> >
> > You don't need a binding, you can look up its meaning in the HTTP
> > specification.  It means, retrieve a representation of the resource
> > identified by that URI.
> 
> Yes, except that that concept may not make any sense whatsoever for
> a given URI scheme.

Ah, but because GET is uniform, it makes sense for all resources and
therefore all URI schemes.  Try it.  It's kinda like asking which Java
objects can't provide a meaningful answer to toString(); all of them
can, of course, because toString() is uniform.  That's why it's an
operation on java.lang.Object.

Earlier you stated that you didn't believe GET, PUT, POST, etc.. were
"special".  I suggest that this is why they are.

> > >  It could mean "get the mail for foo@bar.com".
> >
> > Well, technically, it only means what I said above.  But it could
> > certainly be *used* to return the mail for foo@bar.com.  Good call.
> >
> > >  I also don't know whether that's safe or not.
> >
> > Why not?  GET can be assumed safe by a Web client.
> 
> Really? What if the protocol you're using to GET is POP3 and the
> message gets deleted after you GET it?

Good example.  That would be a bad mapping.  Consider what would
happen if somebody installed software that used that mapping in front
of their mail server, and then proceeded to install a pre-fetching
proxy (which invokes GET on everything that happens past it).  Users
of that software would complain.

> What if the protocol you're
> using to GET is IMAP and the server remembers that the messsage
> has been "read" already. Neither of those are side-effect free
> and thereby not safe.

Also a bad mapping, though arguably not quite as bad as the POP3 one
since message read-status is probably not as important as the actual
message itself.  Less users would complain about that, I imagine.

In both cases though, the ones who complain would presumably stop
using it, thereby reenforcing the safeness assumption.  It's a very
strong feedback loop.

> While one can certainly provide creative bindings for REST verbs
> for SMTP/POP/IMAP operations, IMO that's pretty arbitrary. There's
> no underlying "Web method" concept in those protocols unless I've
> missed something really fundamental.

There's certainly no concept of a "Web method" or even a "Web" in any
of those protocols, but integrating them into the Web requires doing
that mapping/binding you mention.  I also suggest it's not nearly as
arbitrary as you suggest.

Hmm, we might be getting off topic here ...  My bad.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.

Received on Tuesday, 13 July 2004 01:21:26 UTC