[rest-practices] Atom as a generic container? [was Re: Media types]

Mark McLoughlin markmc at redhat.com
Tue Apr 20 15:53:41 UTC 2010


On Tue, 2010-04-20 at 11:19 -0400, Bill Burke wrote:
> 
> Mark McLoughlin wrote:
> >> Atom-style links are nice for references to URL's that are not some sort
> >> of object in the system,
> > 
> > What are they, then? By giving them a URI, we're modelling actions as
> > objects too :-)
> > 
> >> but they're not a particularly nice way to handle object references.
> > 
> > Bill makes the case for Atom links in his book and I agree it makes some
> > sense. But I actually don't particularly care - we're designing a new
> > API and trying to stick with the 'consensus approach' rather than going
> > and re-inventing the wheel.
> > 
> 
> To me, it just feels wrong to have to do a diff on a posted 
> representation to figure out what exact complex logic that has to be 
> triggered.  What I'm starting to do lately is always ask the question, 
> how would I model something in a browser-based application?  For 
> shutdown of a VM, would I really have one monster html form that 
> contained all the mutable bits of state of the VM and submit it all with 
> one post?  No.  I'd break things up into smaller HTML forums embedded in 
> a bigger HTML document.

I'm confused ... are we still talking about:

  <vm href="...">

versus

  <vm><link rel="self" href="...">

Your point sounds more relevant to the async operations thread, no?

> BTW, I'm not sure what you mean by 'consensus approach'.  IMO, REST + 
> Web Services (or in other words non-browser-based REST) is a fairly new 
> area.  I guess what I'm saying is that because things are still 
> relatively new, different things should be tried to improve an API 
> rather than worrying about a 'consensus approach'.

I agree, up to a point - we should definitely feel free to try and
approve on approaches taken by others, rather than blindly follow them

But, given a relatively arbitrary choice between two equally good
approaches, I'd prefer to go along with a rough consensus

We don't want the Deltacloud and RHEV-M APIs (which are closely related)
to be look arbitrarily different for no other real reason than e.g.
whether they were implemented using ruby or RESTeasy

There is value in *some* consistency in the design of our RESTful APIs
within the same product group (if not the whole company) and AFAICT,
that is one of the reasons we set up this list

It'd also be nice if not everyone who wanted to add a RESTful API had to
go through this fairly tortuous discussion of the different
approaches :-)

Cheers,
Mark.




More information about the rest-practices mailing list