Re: MUST a collection be returned as an Atom feed?

[DeWitt Clinton <dewitt@xxxxxxxx>]

You wrote that post a few years back, but I take your mentioning it again to mean your opinion hasn't changed?  Bummer, because some form of content negotiation would certainly still be valuable.

But wouldn't the particular problems you describe be mitigated if the server additionally exposed an explicit 'format' parameter on the URL to force a particular media type?  (This seems to be common practice today anyway.)  That could apply equally to the Collection question here as well, if for some reason someone wanted to serve them as something else in addition to Atom.

-DeWitt

On Mon, Dec 28, 2009 at 8:20 AM, Joe Gregorio <joe@xxxxxxxxxxxxxx> wrote:

In theory, yes, you could put lots of different representations there
and then do
content negotiation. But I would advise against that:

  http://bitworking.org/news/WebServicesAndContentNegotiation

  Thanks,
  -joe

On Mon, Dec 28, 2009 at 8:33 AM, Jan Algermissen
<algermissen1971@xxxxxxx> wrote:
>
> I have raised the following issue on rest-discuss in various forms already.
> Excuse me for bringing it up on this list again. I am just curious what
> people here think.
>
> RFC 5023 says:
>  "Collection - A Resource that contains a set of Member Resources.
> Collections are represented as Atom Feeds."[1]
> Does that mean that an AtomPub server MUST be (at least) respond to a GET on
> a collection URI with an Atom feed
> representation?
>
> I am asking because I consider that to be too constraining. The client
> should not be able to make such an assumption. It should discover at runtime
> that the response is application/atom+xml rather than expect it to be prior
> to the request.
> Jan
>
> [1]http://tools.ietf.org/html/rfc5023#section-3
>
>