Subject: RE: Private extension support (was Re: Q: Put request should return Atom entry?

From: "David Orchard" <[email-masked]>
Date: Wed, 28 Jul 2004 11:26:27 -0700

If I understand this correctly, there is an extensibility point that
needs some more discussion.  Couple of clarifications about the
cardinalities.  

Could:
- a new resource type be created without adding new endpoints?  I would
think not as each new resource type would be deployed at a new endpoint.
- a new endpoint be created without adding a resource type?  I would
think so.

I think that Sam is arguing that we should constrain link extensibility
to be types and endpoints, and not allow arbitrary extensibility of
types/endpoints in links.  

I also wonder about backwards compatibility of interfaces.  If it is
possible to add new resource types, is there any possibility that the
additions will not be backwards compatible?  Generally we think that
adding operations is a backwards compatible change because an old client
simply won't invoke the new operation.  But imagine a new resource type
and related endpoints are added into a site.  Is it possible that a
client may be required to invoke the new resource type at some point?
There is roughly a "workflow" (I tread carefully here) that will require
the client to invoke the resource type.  In this case, it may be
advisable that the client will want to fail earlier rather than later.
This is what I talked about in one of my blog entries that failing a
"protocol" mustUnderstand is quite different in time that a format
mustUnderstand, and you typically want to fail earlier in protocol mUs.

I can easily update the Pace on this if I'm at all on the right track on
these.

What's ironic about atom:link as Sam talks about it is basically a
wsdl:service element.  It contains an address.  WSDL uses a "binding"
which indirectly refers to an interface, and atom:link has skipped the
binding and gone directly to the interface.  Has the issue about
bindings and links been resolved, ie is a reference to a resource
required to support all bindings or at least one?

Dave

> -----Original Message-----
> From: [email-masked] [mailto:owner-atom-
> [email-masked]] On Behalf Of Sam Ruby
> Sent: Wednesday, July 28, 2004 4:13 AM
> To: Ken MacLeod
> Cc: Atom Syntax
> Subject: Re: Private extension support (was Re: Q: Put request should
> return Atom entry?
> 
> 
> Ken MacLeod wrote:
> 
> > "David Orchard" <[email-masked]> writes:
> >
> >>There are 2 different types of extensions that I see:
> >>1. An extension to the protocol is done, ie a new method is added.
> >>2. An extension to the format is done.
> >
> > This is probably obvious to the point of being mundane, but the
> > simplest forms of extensions to the protocol will be in the area of
> > endpoints (collections of resources in a URL-space or active
> > endpoints, like searches) and more Atom-inspired resource types
> > (configuration, blogrolls, users, FOAF).
> >
> > This is all basic REST but nevertheless should be mentioned and
> > recommended as routes of extensibility for Atom because people often
> > forget it's there -- kinda like breathing.
> 
> IMHO, this argument is strenghtened if we keep:
> 
>    <atom:link href="..." type="..."/>
> 
> And weakened if every unique resource type needs a new and unique
> extension to the format.
> 
> - Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Wed, 28 Jul 2004 18:18:52 -0400

> required to support all bindings or at least one?

Sorta.

My tagline is "it's just data".  Sometimes as a conversation starter (or 
stopper) I say things like "I love everything about OO... everything 
except methods".

I want the ability to say "at this URL you are likely to find a resource 
of type text/calendar.  The only operations you can assume the server 
supports are GET, POST, PUT, and DELETE."  And stop there.

I think that titles and perhaps even rel attributes may prove helpful 
for programs to filter on and/or present for selection.

So, if it helps, feel free to think of links as services - without the 
ability to provide a set of bindings to custom operations.

- Sam Ruby