atom-protocol

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: app:accept and Atom entry MIME type Nikunj Mehta Mon May 18 23:00:42 2009


On May 18, 2009, at 7:19 PM, Roy T. Fielding wrote:


On May 18, 2009, at 5:21 PM, Nikunj Mehta wrote:
On May 18, 2009, at 5:06 PM, Roy T. Fielding wrote:
On May 18, 2009, at 11:26 AM, Al Brown wrote:

I believe it is more about extensions to atom. How should a group that builds on top of atom using atom extensibility advertise that it can accept generic atom and/or atom+it's extensions in addition to other potential media types?


Why does it need to?  Why not just let the client try it.

Because the client would have no clue why the request just failed. In effect, it would not "understand" the response even though its intent was clear to the server [1]. This is at the heart of your interoperability argument on atom-protocol from a few years ago [2].

Why would the request fail?

A POST request to a collection could fail because (besides the reasons identified in AtomPub RFC 5023):

1. a non-(atom/cmis)-entry document is posted to a folder URI
2. among other unspecified rules for what makes a valid atom/cmis entry, in the eyes of a given CMIS server, is the presence of a particular extended entry metadata.



In app, this is all done by media types. Both vanilla atom + atom with extensions have the same media type which cause problems.


Won't the extensions be ignored by a server that doesn't want them?

The media type parameter is for use primarily in the app:accept signaling. If a server doesn't require it or doesn't understand it, it can safely ignore it.

Yes, I know.  Don't use the app:accept signaling.  AFAICT, there is
no need to do so.  Just send the AtomPub/HTTP message to the server.

Wait a second. There's a reason we have app:accept. Are you indicating that they are irrelevant? You can always check whether a certain method can be used on a certain resource. However, the app:accept metadata tells you in advance what is likely to happen so you can decide whether or not to attempt an operation. Not every feed is an AtomPub collection, even if it is coming from an AtomPub server.



I am not sure leveraging categories as the signaling mechanism fits.

I agree.  Atom categories are analogous to folders in CMIS.
<snip>