Subject: Content type - and content negotiation

From: "Erling Wegger Linde" <[email-masked]>
Date: Wed, 2 Apr 2008 11:51:03 +0200

Hi,

I am using APP with ROME. I wonder if it is correct that the APP
standard supports "text/plain", "application/xml",
"application/rdf+xml" etc. in the <content type=""> - or just "text",
"xml" etc. as I think the current version of ROME supports now.

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.

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">. 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. I guess the HTTP Accept header is already
used for "application/atom+xml" so is there any other way than the
<link..> approach? Any other HTTP headers that could be used? Could
you specify "application/xml" as the second preferred data format, and
would it be logical to let the server use this to decide which format
to serve in the content?

Do you agree that this is a weakness of the APP, or are there some
clever workaround / best practices regarding this issue?

Thanks, Erling

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 7 Apr 2008 20:01:28 -0700

> 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>

> 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.

> 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