On 02/04/2011, at 4:58 PM, Julian Reschke wrote: > On 02.04.2011 17:32, Cameron Heavon-Jones wrote: >> ... >>>> Personally I'd add "should integrate well with servers which already >>>> support >>>> PUT and DELETE, such as WebDAV servers" >>> >>> sounds ok. >>> >> >> I would hesitate at making references to WebDAV. This is an extension of >> HTTP and as such introduces additional functionality which, IMO, is not >> appropriate for the top-level specification. >> ... > > As a normative reference, no. As a use case to be considered, yes.
Ahh, agreed. I think it provides a great example of the kind of system which would benefit from the additional functionality however it is its extension to the http protocol which is negating it from being a drop-in replacement for a client user interface. > >> ... >> >> I think PUT and DELETE should follow POST in regards to the action URI. >> Personally i'm not too keen on GETs producing URIs and would prefer there to >> be at least the option of embedding the form data. Maybe this could be >> specified as a new encType - "text/uri" or somelike... >> >> why would the need for a template arise? to PUT to a resource implies the >> resource already exists, it can be used as a creational operation as >> described in the example but that would seem to be leeking server-side >> implementation details (the id) into the client and introduce coupling. > > There are use cases for PUT-to-create. Namely, when you *want* to enable the > client to name the resource. Sure, so the template would be based on some form field then? I would probably just model that as a POST to the higher resource, in this case, http://www.example.org/users/ I can see the use case, but i thought the introduction of uri templates would probably be far greater scope...? > >> ... >>> Yeah, Snell's notion seems closer to what might be desireable. Of >>> course, having agent add a new (optional) header will not likely >>> improve the results from any existing servers. >>> >> >> I suggested using the Accept header as this is how content negotiation works >> everywhere... why reinvent what is already there? Why should it be ignored >> just because the request is from a form submission? > > The reason why I'm nervous is that I'm not sure that Accept: ever has used > for this purpose, and it also doesn't convey the intent of a client. I'm not sure what purpose you're referring to... the purpose of defining the format of the response? It's not supposed to convey the intent of the client - that is for the URI, method, form data. I guess the entire request conveys the whole intent of the client, but this should include what format they want in response. > Remember that "Accept: text/html" doesn't tell the server *what* the client > wants to see, just the format. So do you return a status message, or a > representation of the resource? The content of the response should be whatever the resource deems to be the content...it could be a status message or it could be a full representation. It doesn't really matter, but the important thing is that the user gets a content response if the resource defines one. I think that for PUT, POST, DELETE i am thinking more in terms of a URI + body = Resource in this regard... in that context, the resource is unique and possibly unreferencable but you can't bookmark a POST, PUT or DELETE. In this regard you would be able to have a resource which technically doesn't exist - a failed request to create a resource will return back a representation at that address but only in the context of the request that was recieved. This would be returned using the appropriate HTTP response code as it does for automated agents but for some reason all User-Agent responses have been forced to return 200s, even for errors. Let me create a sample: *** REQUEST GET /users/;create HTTP/1.1 Host: www.example.org Accept: text/html ... *** RESPONSE 200 OK HTTP/1.1 Content-Type: text/html ... <html> ... <form action=”http://www.example.org/users/123” method=”put”> <input name=”user-name” value=”” /> <input name=”hat-size” value=”” /> <input type=”submit” /> </form> ... </html> *** REQUEST PUT /users/123 HTTP/1.1 Host: www.example.org Accept: text/html Content-Type: application/x-www-form-urlencoded Content-Length: nnn user-name=mike&hat-size=small *** RESPONSE 201 CREATED HTTP/1.1 Content-Type: text/html ... <html> ... <ul> <li>user-name: mike</li> <li>hat-size: small</li> </ul> ... <html> ALTERNATIVE: Validation Error *** RESPONSE 400 BAD REQUEST HTTP/1.1 Content-Type: text/html ... <html> ... <form action=”http://www.example.org/users/123” method=”put”> <p class="error">User name already exists</> <input name=”user-name” value=”mike” /> <p class="error">Unknown hat size</> <input name=”hat-size” value=”small” /> <input type=”submit” /> </form> ... <html> ALTERNATIVE: Accept: application/xml *** RESPONSE 201 CREATED HTTP/1.1 Content-Type: application/xml ... <xml> <user name="mike" hat-size="small"/> <xml> ALTERNATIVE: Accept: application/xml *** RESPONSE 400 BAD REQUEST HTTP/1.1 Content-Type: application/xml ... <xml> <errors> <error field="user-name" reason="NON_UNIQUE"/> <error field="hat-size" reason="UNKNOWN_ENUM"/> </errors> <xml> > >> I think the focus on existing servers and services is unhelpful for the >> specification of new features. Of course they won't be supported >> retrospectively but it's about allowing new services to function fully. > > That is true. > > What I want to avoid though is that a server can't support PUT for both forms > and other kinds of clients on the same URI. Isn't this a requirement of HTTP? The same URI should be capable of accepting and producing different content based on the Accept and Content-Type headers. So, these should all be valid: *** REQUEST PUT /users/123 HTTP/1.1 Host: www.example.org Content-Type: application/x-www-form-urlencoded Accept: text/html user-name=mike&hat-size=small *** REQUEST PUT /users/123 HTTP/1.1 Host: www.example.org Content-Type: application/xml Accept: application/xml <xml> <user name="mike" hat-size="small"/> </xml> *** REQUEST PUT /users/123 HTTP/1.1 Host: www.example.org Content-Type: application/json Accept: application/json {user-name="mike" hat-size="small"} > >> Current implementations of PUT and DELETE definitely won't be returning >> content but then these services currently aren't designed for human >> interaction anyway. They will require forms to be created and they will >> require the HTML results of processing those forms to be created too. > > Sorry? They are not designed for *browser* interaction, but still they'll > interact with users. Yeah...i have the opinion that if it's not possible in a browser a human can't do it :) Not without a custom built desktop client... <shudder> > >> ... >>>> How *are* they handled by UAs? (Is this in HTML5?). >>> Excellent question<g>. I have _assumed_ since servers are free to emit >>> 201/202/204 for POST today that the HTML WG had no real concern for >>> this case. It's not clear to me why adding PUT/DELETE to the list of >>> supported methods alters the importance of handling these types of >>> responses, but I'm open to hearing more about it. >>> >> >> I would suggest that ALL http responses MUST be rendered by the user agent. >> It should make no matter what the response status is for a user to see the >> result of their request. > > Is this the case today? Need test cases. > > > ... > > Best regards, Julian No this isn't the case today, but i believe it makes far more sense and is the role User-Agents are meant to be filling. It would be such a small change to make as well, pretty much the recommendation is for User-Agents to ignore the response code and just render the content. Thanks, Cam
