The 'service.post' URI in the AtomAPI can be sent an Atom <entry> with any one of a number of 'type' attrubutes. For example, a client could send an <entry> with the following <content> element to upload a JPEG image to the server:
<content type='image/jpeg' mode='base64'> 0912384heb0329289 a830103.... ....ha37ba091a0a </content>
There currently isn't any mechanism by which a client can discover which mime-types a server supports.
One possible solution is to have the 'service.post' URI respond to a GET and the response to that GET would be a partially filled in Atom <entry> with multiple <content> children, one for each type that the server accepts.
For example, if a server accepts only text/plain, text/html and image/jpeg, then this is what would be returned from doing a GET on the 'service.post' URI:
<entry xmlns="http://purl.org/atom/ns#"> <title></title> <id>tag:blog.example.org,2003:3.2397</id> <issued></issued> <modified></modified> <content type="text/plain"/> <content type="text/html"/> <content type="image/jpeg"/> </entry>
This proposal allows each server to explicitly enumerate the mime-types it supports. At the same time is re-uses the Atom format to present that information.
This proposal adds another HTTP method that the 'service.post' URI must support. Note that GET on the 'service.post' URI is currently unspecified.
Many services who currently support the Atom API use the same URI for service.feed and service.post because the nomenclature makes sense. Overloading service.post would require a different nomenclature.
DamionAlexander - Instead of using a GET on the PostURI, methinks it would be more beneficial to add a link with a @rel type of "service.accept". This link could be included in the Atom feed in the Feed section and in the individual entry sections. The one in the Feed section would relate to PostURI and the one in Entry elements would be for what that specific entry accepts (EditURI). The format of what is returned from that link I am not sure of. There is some discussion going on the list now about MIME formats (Thread: "multiple <content> elements without @type=multipart?") that would affect the returned format.
[AsbjornUlsberg] I'm not sure what I think about this, other than that I feel the proposed method might be a bit too complicated. Also, I find it not extensible enough. The current AutoDiscovery proposal is just a <link> in the HTML file, which points directly to the feed. How about adding an additional, optional, file between the feed and the HTML document, in which you plunge all discovery information needed? Here you place all 'accept' information, the URL to the feed, etc. I mention this at the bottom of AutoDiscovery, btw.