[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PaceReplaceTypeWithAccept

On Nov 28, 2005, at 4:14 PM, Eric Scheid wrote:
On 29/11/05 6:58 AM, "James M Snell" <jasnell@xxxxxxxxx> wrote:

 <link rel="edit" href="http://example.org/1.atom"; />
 <link rel="edit-content" href="http://example.org/1.png"; />
 <content type="image/png" src="http:/example.org/readonly/1.png" />

any reason you don't want to do this:

  <link rel="edit" href="http://example.org/1.atom"; />
  <content type="image/png" src="http:/example.org/readonly/1.png"

clearly de-de-couples the <content> element to the @href for editing

Whatever happened to the idea that Atom was based on REST principles of resources that have identifiers which a client could apply a method to and see if that method worked by looking at the response?

Atom doesn't need rel="edit" or rel="editcontent" or app:edit-content.
All it needs is one identifier for the entry and an identifier for
each <content>.  Everything else can be determined by the client when
it accesses the server, assuming Atom has properly defined the meaning
of redirects.  If you have a desperate need to tell clients that they
should not try to edit a given resource, then add

Link: <other-URI>; rel="source"

to the header fields of the HTTP responses.  This is not Atom-specific