In "Is It Atompub?", James Snell discusses how an arbitrary binary file could be posted to a feed via AtomPub, along with it's meta-data, at the same time, in a single HTTP transaction.
I'm assuming here that by "metadata", James means "stuff in the media link entry".
All James' options look like reasonable things a server CAN do. But it raises the question: how does the client know which of these methods is actually supported? I guess one of the answers is via exposing capabilities via features, which is something James is currently working on.
I think the answer is, if you're writing generic-ish client code, that you can't, today.
Doesn't mean you can't get close. The sequence described in Section 9.6.1 of the brand spankin new RFC 5023 seems to describe it pretty well. You can shortcut through that example, by issuing a PUT against the entry returned by the original POST, I assume, eliminating the secondary GET. It's just not one transaction anymore, it's two.
I'll also add that James' first option: have the server retrieve the meta-data from the binary blob's intrinsic meta-data, seems wrong. It will require the server to know about meta-data formats for all manner of binary blobs users might want to store. I think it's fine for a server to support that, if they want, but it doesn't seem to right to assume that every server DOES support it. But don't get me wrong, I would love to have the exif data extracted out of my photos upon upload.
So the next interesting question is, if the server DOES populate the meta-data for the resource on my behalf, based on the resource, how do I as a generic client know that? Check for a non-empty atom:summary element?
BTW, I hadn't gotten a chance to extend thanks to the folk working on the Atom and AtomPub specs, for all the work they've done over the years. Standards work is hard and thankless. Kudos all around.
---
Edited at 9:03pm: ops - I wanted to title this "only the server knows" not "only the shadow knows"
