Thomas Broyer wrote:
>[snip]
> First, there's no reason for the MUST in "MUST be an Atom Entry
> Document representing the newly-created resource"; I'm still
> uncomfortable with the second paragraph, and I see no reason for the
> SHOULD in "SHOULD also return a response body".
>
This has been debated several times already. I don't see what the MAY
buys us in terms of interop as it leads to the possibility that, with
some server implementations, I could post an entry and have absolutely
no idea how to go back and edit it, or even find it later. Limiting the
SHOULD and MUST to 201 responses is a compromise. If someone returns a
202 Accepted, or anything other than 201, it can return any kind of
representation it wants. I think that's perfectly acceptable.
>[snip]
> Section 8.4, the second paragraph says there *are* two resources,
> while you were saying the spec should not go for one or another.
> Also, if you can't POST an Atom Feed (or at least, POSTing an Atom
> Feed is not defined as a request to create a new resource as
> represented by the feed), why not simply using a link with rel="edit"
> and a "type" attribute (different from application/atom+xml) instead
> of a new rel="edit-media"? So <link rel="edit"
> type="application/atom+xml" href="..."> is used to edit the "media
> link entry" and <link rel="edit" type="..." href="..."> is used to
> edit the "media resource".
>
I'd be happy with this
> Section 7.2.4 (the "app:accept" element): there's no need for the
> special value "entry", as we don't define POSTing an Atom Feed
> Document (see comments above about section 8.4). An extension defining
> such a thing will just need an extension element in the
> introspection/service document (instead of a special value "feed", for
> example). Accepting representations of a media type doesn't mean you
> will accept all of them, so you'll be right refusing Atom Feed
> Documents even if you have
> <app:accept>application/atom+xml</app:accept> in the
> introspection/service document.
>
I'd be fine with this so long as there is language that discusses the
Entry document vs Feed document issue.
- James
