[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MUST a collection be returned as an Atom feed?
On Mon, Dec 28, 2009 at 12:08 PM, DeWitt Clinton <dewitt@xxxxxxxx> wrote:
> You wrote that post a few years back, but I take your mentioning it again to
> mean your opinion hasn't changed?
Correct, it 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.)
The explicit query parameter makes it a different URI, so that does
solve the problem, and while it has become a common practice, we only
have convention at this point, no standard way of discovering the available
representations and their URIs.
What use cases are you thinking of that would benefit from conneg?
> 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
> 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:
>> 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."
>> > 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
>> > http://tools.ietf.org/html/rfc5023#section-3