Erling wrote:
> If it supports <content type="everything"> I am glad, this means that
> the server could understand different content formats POSTed or PUT to
> the server on the same edit uri.
If you POST anything besides application/atom+xml, then the entry will
(probably) be a media-link entry, which looks like:
<content src='document.txt' type='text/plain'/>
If you post an Atom entry, you can post something like this:
<content type='text/plain'>Document content goes here.</content>
> However, I wonder if there are any other way to allow content
> negotiation of the format of the content type than using <link
> rel="N3" type="text/n3" url="otherurl">.
Usually, you link to alternate representations using:
<link rel='alternate' type='text/n3' url='otherurl'/>
Or just:
<link type='text/n3' url='otherurl'/>
Since 'alternate' is the default link type.
> It seems to me that the downside of using APP as a Web Service
> Protocol is that it is not as HTTP-linked as I thought.
> Do you agree that this is a weakness of the APP, or are there some
> clever workaround / best practices regarding this issue?
RFC 5023 specifically avoids specifying if/when/how HTTP content
negotiation is integrated into AtomPub. If you need to do HTTP content
negotiation, then you should usually ensure that the server
automatically derives all the variants from whatever representation the
client POSTs/PUTs, and you should usually expose the multiple variants
only at the publishing side, not the editing side. That way, whatever
AtomPub clients you use will not have to deal with the content
negotiation at all.
- Brian
