<br><br><div><span class="gmail_quote">On 11/5/07, <b class="gmail_sendername">Sean Dague</b> <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On Mon, Nov 05, 2007 at 10:11:39AM +0100, Stefan Andersson wrote:<br>> Uh, not entirely sure how to read the current state of the draft, but just wanted to make sure that<br>> POST /assets/new should returd assetid in response, as we can't rely

> on everybody 'playing nice'. My initial thought was that it returns the full object, with UUID in place.</blockquote><div> I think it is a bad idea to let the asset server assign the asset id, this will make it necessary for the client to wait for the asset id to be returned, leading to a lot of situations where the client will hold an "internal" id, and then later fix up the internal representation with the actual and real asset id.

<br><br>One of the beauties, almost the only one I can think of actually, by using UUID's as a data type for id's is that they can be created and assigned client side, without fear of collision and/or elaborate schemes for ensuring uniqueness. 

By implementing a protocol where the assets server is responsible we force the hand of the client designers and architects to either create assets in a synchronous process or force them into a situation where assets have two id's, an "internal id" and a public "external id". I would strongly recommend that we leave it up to the client to assign the asset id.

<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> The Draft should also define the response on all commands; I'd suggest

<br>> we use an xml posted object response; something like<br><br>Why don't we just use HTTP response codes instead (full list at:<br><a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html">http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

</a>) > GET: > The binary asset, > Content-type: xxx Besides content also setup the response codes correctly 200 - success 401 - forbidden 404 - not found</blockquote><div> I agree with using response codes, anything else will be too "XML-RPC"'ish, and not really rest. Unfortunately this will require some rewriting of the basic HTTP server implementation code we use, which will impact a lot of code. I am not saying that we shouldn't do that, but lets do one thing at a time.

<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> DELETE:<br>> <DeleteResponse><br>> <Result success="true">Ok</Result>

<br>> </DeleteResponse><br>> Content-type: application/xml</blockquote><div><br>we need to decide what our content type is going to be, MW clearly likes "text/xml", this says "application/xml", I have tried to discover, what the correct content-type is, but have found nothing conclusive the "

<a href="http://www.ietf.org/rfc/rfc3023.txt">XML Media Types</a>" RFC seems to leave it up to us, but I do propose that we are consistent.<br></div><br></div>I think it is too early days to commit to a "formal" spec, I am convinced that the current layout will change quite a number of times, from now and til version 

0.6.<br><br>/tleiades<br>