Re: #230: Considerations for registering new methods

On 19/10/2010, at 9:11 PM, Julian Reschke wrote:
>> When it is necessary to express new semantics for a HTTP request that aren't specific to a single application or media type, and currently defined methods are inadequate, it may be appropriate to register a new method [ref].
>> 
>> New methods SHOULD be potentially applicable to any resource. I.e., they should not be specific to any particular media type, "type" of resource, or application.
> 
> General question: is the use of RFC2119 keywords appropriate here? What about the "should" in the 2nd sentence?

In as much as they describe requirements for the registration of new methods, and what is considered a conformant application, I think it's appropriate. Using the keywords has the advantage of unambiguously communicating the requirements.

However, I'm not lie-down-in-the-road about using them.


>> New methods MUST NOT prohibit a message-body on either the request or the response message; however they MAY specify that only a zero-length body is allowed.
> 
> I think it would be good if we rephrased that as a general statement about HTTP methods, and then pointed out that new methods need to follow that.
> 
> Such as:
> 
> "Due to the parsing rules defined in ..., HTTP methods cannot prohibit the presence of a message-body on either the request or the response message (with the single exception of HEAD responses). Definitions of new methods cannot change this rule, but they can specify that only zero-length bodies (as opposed to absent bodies) are allowed."

Seems reasonable.


>> New methods MUST define whether they are safe [ref] and whether they are idempotent [ref]. They MUST also state whether they can be cached [ref to p6]; in particular what conditions a cache may store the response, and under what conditions such a stored response may be used to satisfy a subsequent request.
> 
> Agreed. We'd better make sure that our method definitions give a good example how to do this ;-)

Yup :)


>> New methods SHOULD explain how conditional request headers [ref] affect the response (if there is any effect).
> 
> Wow. I always thought they apply to any method; thus extensions methods can't be special. Maybe this deserves a separate issue?

Well, we could say that 304 is specific to GET/HEAD, and all other methods use 412 for failed conditions, but that bit of glue seems to be missing ATM. 

We should probably also warn that clients can't take it for granted that a resource will support conditional requests (if we don't already); this can be surprising if you're expecting it on POST/PUT, etc.

It sounds like we should remove this sentence and open two new issues.


>> HTTP methods SHOULD be registered in a document that isn't specific to an application or other use of HTTP, so that it's clear that they are not specific to that application or extension.
> 
> That's very vague (what does "other use" mean).

That can be dropped.


> Maybe we should start with examples, and then come up with guidelines?
> 
> - PATCH (RFC 5789) is certainly a good example for a generic definition.
> 
> - MKCALENDAR (RFC 4791) is certainly a good example for something that shouldn't have been a separate method.
> 
> I think most of us agree on the above. But what about things between these extremes, such as WebDAV?


What this is saying is that the WebDAV methods should have been registered in a non-WebDAV specific document, to clarify that they can be used in other contexts.



--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 20 October 2010 00:32:45 UTC