2006/2/28, Andreas Sewe <[EMAIL PROTECTED]>: > * Are HTTP redirects (3xx status codes) allowed when Retrieving an > Introspection Document (5.1), Retrieving a Resource (5.3.1), or Listing > Collection Members (5.4)? The draft is silent on this; possible status > codes aren't specified for GET requests. All that is said is that "The > server responds with a [introspection] document", "with the > representation of the resource", and "with an Atom Feed Document > containing the IRIs of the collection members," respectively.
Isn't section 5.5 enough? "The Atom Protocol uses the response status codes defined in HTTP to indicate the success or failure of an operation. Consult the HTTP specification [RFC2616] for detailed definitions of each status code." or "success or failure" can be misleading? > But an APP server might, for example, want to map collection IRIs like > <http://example.org/themen/beispiel> to > <http://example.org/topics/example> via an HTTP redirect, making it > easier for people to memorize IRIs by exposing them in their own > language (in the above example, German). And there are probably other > use cases for this as well. Yes, maybe even more "obvious": GET /my-collection HTTP/1.1 Host: example.net HTTP/1.1 307 Temporary Redirect Location: http://example.net/my-collection/ (Appending a slash) > * When "Creating resources with POST" (8.1) "collections MAY impose > constraints on the media-types that are created in a collection and MAY > generate a response with a status code of 415 ("Unsupported Media > Type")." A clarification might be needed, however, since constraining > media types is not sufficient in order to prevent POSTing Atom feeds to > entry collections; both Atom feeds and entries have a media type of > "application/atom+xml". > > What about rewording the above to "collections MAY impose constraints on > the formats that are created in a collection and MAY generate a response > with a status code of 415"? This uses the generic term "format", > following RFC 2616's explanation of status code 415. Furthermore it > omits the "Unsupported Media Type", since it can be misleading. I think the 422 status code added by WebDAV better suits the need. http://www.webdav.org/specs/rfc2518.html#STATUS_422 How about "collections MAY impose constraints on the formats that are created in a collection and MAY generate a response with a status code of 415 (Unsupported Media Type) or 422 (Unprocessable Entity)"? > * Also, the wording of "Creating resources with POST" (8.1) and "Media > Collections" (8.3) may need some further refinement, since 8.1 states > that "collections MAY impose constraints [...]" whereas 8.3 states that > "Media Collections are collections whose member representations are not > constrained." > > What about changing 8.3 as follows: "Media Collections are collections > whose member representations are not constrained to Atom Entries. It MAY > impose, however, further constraints on the formats created therein (see > 8.1)."? +1, but actually I have a bigger problem with Media collections… > * Is the inconsistency between "application/atomserv+xml" and the > file extension of ".atomsrv" intentional? If not, could you please bring > those to in line since it's easy to forget about an 'e' or insert one > when it is not needed. (Personally I prefer "atomsrv" over "atomserv" > since the former is slightly shorter, but in the end I don't > mind, as long as it is handled consistently.) How about using "svc" instead of "srv" or "serv"? "svc" looks more like "service" than "srv" or "serv", which look more like "server", which is not appropriate. application/atomsvc+xml Or maybe just application/atom-service+xml > * What about turning the <app:member-type> element into an attribute, > @type, on <app:collection>? At least in my understanding > <app:member-type> serves a purpose similar to the @type of Atom Text and > Content Constructs. My position on this is to "refactor" Entry and Media collections… -- Thomas Broyer
