Re: [Fwd: Re: PUT and DELETE methods in 200 code]

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

Received on Saturday, 2 April 2011 17:15:42 UTC