Aleksander Slominski wrote:
> James M Snell wrote:
>[snip]
>> Optional. There is a proposal on the table that says if a response
>> entity is returned, it should be an atom entry.
>>
> hi,
>
> thanks for answers and giving them from an implementation perspective!
>
> if the <atom:entry> entity is not returned in HTTP response how the
> client can know that server did update atom:entry representation (such
> as put new atom:id) or not?
>
> it would be nice to have some way to know it (may different HTTP status
> code) so the client does not need to do spurious GET after each POST/PUT ...
>
IMHO, the spec should not mandate that the entry be returned with the
response but as a best practice, servers that can probably should.
>>> is it allowed to POST atom:entry with binary content to media
>>> collection? [1]
>>>
>> The media resource created would be an Atom entry document.
>>
> great that is what i hoped for however i am not 100% sure on what should
> be returned in Location.
>
It would be no different than if you posted any other type of resource.
> should Location header point to atom:entry or actual binary resource (as
> in section 12)? (it was already asked but i could not find a definitive
> answer http://www.imc.org/atom-protocol/mail-archive/msg04577.html )
>
If you post an entry document to a media collection, the entry document
would be treated as if it were any other binary resource of any other type.
A. Post the media resource
POST /media-collection HTTP/1.1
Host: example.org
Content-Type: application/atom+xml
Title: Bar
<?xml version="1.0" ?>
<entry>
<id>urn:foo</id>
<title>Foo</title>
...
</entry>
B. Created!
HTTP/1.1 201 Created
Date: ...
Location: /media/abc123
C. Get the media collection feed
GET /media-collection HTTP/1.1
Host: example.org
D. The posted resource shows up in the feed. Note the content element.
The media resource has editable metadata (the edit link)
HTTP/1.1 200 OK
Date: ...
Content-Type: application/atom+xml
Content-Length: nnnn
<?xml version="1.0" ?>
<feed ...>
...
<entry>
<id>tag:example.org,2006:/media/abc123</id>
<link rel="edit" href="/media/abc123.edit" />
<title>Bar</title>
<updated>...</updated>
<author><name>james</name></author>
<content type="application/atom+xml"
src="/media/abc123" />
</entry>
...
</feed>
E. Get the media resource
GET /media/abc123 HTTP/1.1
Host: example.org
F. Return the resource
HTTP/1.1 200 OK
Date: ...
Content-Type: application/atom+xml
Content-Length: nnnn
<?xml version="1.0" ?>
<entry>
<id>urn:foo</id>
<title>Foo</title>
...
</entry>
G. Get the editable metadata for the resource
GET /media/abc123.edit HTTP/1.1
Host: example.org
H. Note that this is the metadata from the feed, not the resource
HTTP/1.1 200 OK
Date: ...
Content-Type: application/atom+xml
Content-Length: nnnn
<?xml version="1.0" ?>
<entry>
<id>tag:example.org,2006:/media/abc123</id>
<link rel="edit" href="/media/abc123.edit" />
<title>Bar</title>
<updated>...</updated>
<author><name>james</name></author>
<content type="application/atom+xml"
src="/media/abc123" />
</entry>
I. Update the editable metadata
POST /media/abc123.edit HTTP/1.1
Host: example.org
Content-Type: application/atom+xml
Content-Length: nnnn
<?xml version="1.0" ?>
<entry>
<id>tag:example.org,2006:/media/abc123</id>
<link rel="edit" href="/media/abc123.edit" />
<title>This is an atom entry media resource</title>
<updated>...</updated>
<author><name>james</name></author>
<content type="application/atom+xml"
src="/media/abc123" />
</entry>
J. Response
HTTP/1.1 204 No Content
Date: nnnn
K. Get the media resource
GET /media/abc123 HTTP/1.1
Host: example.org
L. Return the resource. Notice no change, only the metadata was edited
HTTP/1.1 200 OK
Date: ...
Content-Type: application/atom+xml
Content-Length: nnnn
<?xml version="1.0" ?>
<entry>
<id>urn:foo</id>
<title>Foo</title>
...
</entry>
M. Check the media collection feed
GET /media-collection HTTP/1.1
Host: example.org
N. The feed shows the edited metadata
HTTP/1.1 200 OK
Date: ...
Content-Type: application/atom+xml
Content-Length: nnnn
<?xml version="1.0" ?>
<feed ...>
...
<entry>
<id>tag:example.org,2006:/media/abc123</id>
<link rel="edit" href="/media/abc123.edit" />
<title>This is an atom entry media resource</title>
<updated>...</updated>
<author><name>james</name></author>
<content type="application/atom+xml"
src="/media/abc123" />
</entry>
...
</feed>
O. Update the media resource
POST /media/abc123 HTTP/1.1
Host: example.org
Content-Type: image/png
Content-Length: nnnn
{binary image}
P. Success
HTTP/1.1 204 No Content
Date: nnnn
Q. Check the media collection feed
GET /media-collection HTTP/1.1
Host: example.org
R. Note the different type on the content element.
HTTP/1.1 200 OK
Date: ...
Content-Type: application/atom+xml
Content-Length: nnnn
<?xml version="1.0" ?>
<feed ...>
...
<entry>
<id>tag:example.org,2006:/media/abc123</id>
<link rel="edit" href="/media/abc123.edit" />
<title>This is an atom entry media resource</title>
<updated>...</updated>
<author><name>james</name></author>
<content type="image/png"
src="/media/abc123" />
</entry>
...
</feed>
> in such case does the client needs to parse <atom:entry> to find the
> location of the atom entry from [EMAIL PROTECTED] - does it have to be
> present?
>
[EMAIL PROTECTED] is generally for feed documents. it can be used for
entry documents, but APP doesn't require it. The edit link is required
for entry collections, optional for media collections.
> it seems that [EMAIL PROTECTED] can not be used as may point to (X)HTML
> page right?
>
> anyway hopefully that will get clarified in next version of spec
> (http://www.imc.org/atom-protocol/mail-archive/msg04744.html )
>>> for entry collections: is it allowed that <atom:entry> POSTed has no
>>> atom:id so the atom:id is assigned by server? in that case should
>>> <atom:entry> be returned in 201 Created response to let client know that
>>> it needs to update its representation of atom:entry (and get required
>>> atom:id)?
>>>
>> The atom entry MUST be valid... meaning it must have an atom:id. Our
>> implementation ignores the incoming atom:id and replaces it with our own id.
>>
> do you use any particular URI to indicate that this id is to be replaced
> by APP server?
No. such a URI has been discussed but there was never any consensus.
>>> how are current implementations of APP dealing with it?
>>>
>>> are there available captures of HTTP traffic for perusing (something
>>> like [1])
>>>
>>>
>> Later tonight I'll capture some traces and post 'em.
>>
>>
> that would be great.
>
Sorry I didn't send traces as promised, ended up with two kids with the
flu. :-( ..
- James
