Comments on: Atom Is Not SOAP

By: Hipermídia e contratos dinâmicos: menor acoplamento | blog.caelum.com.br

Hipermídia e contratos dinâmicos: menor acoplamento | blog.caelum.com.br — Thu, 17 Dec 2009 12:08:18 +0000

[...] ATOM é um exemplo que suporta por padrão contratos dinâmicos: ao seguir o Must Ignore, ganhamos forward e backward compatibility. Contratos dinâmicos fornecem dicas para os frameworks, permitindo ao servidor guiar o cliente naquilo que pode executar ou acessar. [...]

By: pkeane (Peter Keane)

pkeane (Peter Keane) — Fri, 01 May 2009 00:43:33 +0000

@realworldobject I mean pretty much what Subbu is saying: http://tinyurl.com/cqfvjw .

By: Mike Amundsen

Mike Amundsen — Thu, 30 Apr 2009 17:23:44 +0000

You know, I almost titled my post “Atom is not SOAP” or something along those lines!

By: subbu

subbu — Thu, 30 Apr 2009 17:01:25 +0000

but if you point a generic Atom client (supporting the standardized extensions such as paging and licensing) at a feed and you GET some value out of that, then using Atom did deliver something useful.

That is a great point. Folks designing Atom based representations should look through the eyes of a feed reader and measure the effectiveness of their design. If a feed reader is not seeing the essentials bits of the representation, then it is time to rethink.

By: dret

dret — Thu, 30 Apr 2009 16:51:31 +0000

while you’re certainly correct that “Atom is not SOAP”, i prefer to look at Atom/AtomPub as a design pattern for RESTful services. as with all design patterns, they have limits and it is not always easy to say whether a given scenario is within or outside of these limits. but as long as your set of resources can be reasonably organized in collections with only secondary associations, Atom/AtomPub is a good pattern to consider. if your resources have more structure and the structure is inherent to the problem domain, then Atom/AtomPub may not be a good fit, or only as a general-purpose entry point to the resources you’re managing.

generally speaking, we (as the REST-interested community) lack discipline in coming up with design patterns for REST and with good guidance on when to apply them and when to not apply them. i a looking forward to your book to include some guidance for that, it’s really needed.

Atom’s popularity also is its curse: the more widespread it becomes, the more people will extend it, creating extensions with overlapping or even competing semantics. dealing with those will not be easy, and generally speaking, i agree that Atom-based services which critically depend on extensions usually are a bad idea. but if you point a generic Atom client (supporting the standardized extensions such as paging and licensing) at a feed and you GET some value out of that, then using Atom did deliver something useful.