2006/1/31, David Powell <[EMAIL PROTECTED]>: > I had thought that the entry is "created" as soon as it is > created/conceived offline, and the POST operation just tells the > server about it.
+1 This is consistent with import/export facilities too. > The other way of looking at it is, that the entity body of the POST > request is just a prototype representation and the entry is "created" > by the server after the POST request. > > Reading the draft more carefully, perhaps the second option is the > closest? The draft talks about "creating resources" whereas it's just about creating an *URL* for the resource. > What can be said of the original POSTed representation then? Is it a > representation of a dummy entry, only relevant whilst the entry is > being edited offline (but would still require a globally unique id). > Or is it a representation of nothing - if so what is the atom:id > identifying? In last fall discussion, it was proposed using an atom:id generator (the client asks the server for a globally unique atom:id to use within a subsequent POST), an atom:id template (a client processing the template with some parameter values is guaranteed to have a globally unique atom:id) or a sentinel atom:id (either a globally reserved IRI or IRI template –e.g. every IRI using an example.[com|net|org] authority–, or a server-specific sentinel atom:id exposed in the service/introspection document); or even a combination of any of those. Everyone of these choices can be added later, as an extension to the protocol. > Furthermore, if we agree that the atom:id of the POST request > identifies something, then could we define the model such that the > atom:id identified something that would allow servers to implement > idempotent POSTing? What do you mean by "idempotent POSTing"? - that a server ignores previous (or subsequent) POSTs using the same atom:id? - the ability to update an entry by POSTing its updated representation to the collection, instead of PUTting it to its IRI? My implementation will (not done yet) fail with a 409 (Conflict) when a client POSTs an entry with an atom:id already used within the system. -- Thomas Broyer
