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.
...
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.
...
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.
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?
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.
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.
...
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
