Is ATOM the way to do REST ?

James Snell answered to the questions I posted earlier, thanks James.

In response to "Do you think AtomPub is the way to do REST ?" James replies (omitting the first sentence for brevity :-)) :

"There’s really only one way to 'do REST'. Atompub adhers to the REST architectural style to solve a particular range of problems. For that particular range of problems, Atompub is a very good solution".

I liked the answer. For the record, I agree that people wishing to understand REST better should look at the way AtomPub has been designed. My own awareness of AtomPub has risen a lot recently after James Strachan joined IONA :-)

That said, the reason I asked the question that way is that , as far as I can hear and understand, quite a few people reckon that if you want to do REST then just use Atom, due to the fact its format is understood by various tools, etc.

Here's what interests me. In my own understanding, exposing public data as REST resources is promising. AtomPub is good for dealing with collections of data, and thus it can be used not only to deal with feeds. It primarily deals with two levels of resources, parent resources (collections) and their children, entries.

So I'm wondering, would AtomPub be a good fit for dealing with RESTful services where parent resources have more than one descendant, ex : collection/child1/child2/child3 ?

Offtopic : I also liked James's response to "What is a better way to protect investments made into WS-* ?" :

"We should be more concerned about protecting investments in our business goals than in protecting our investments in any specific set of technologies."

It's interesting, I'm wondering how wide is a gap between these 2 concerns ? I'll muse more about it later.