Better identifier for HTTP resource's wildcard accessor

[chamil321]

The accessor confines the resource to the specified HTTP method. In this instance, only GET requests are allowed.

resource function get hello() {
    //...
}

When implementing a passthrough/proxy resource, the user needs to allow any HTTP method to go through the resource. To fulfill the requirement, default identifier was suggested.

Fact 1

There have been use-cases where custom HTTP methods such as COPY, MOVE which not specified in the spec also has been used. Therefore we do not restrict the allowed method to a certain definite set. Even though we say default, in fact, we do not have such a default set. So any could be a possible suggestion for the accessor.

Fact 2

During the dispatching, if two similar resources are defined in service, one with a specific accessor and one with default, The most specific resource will get invoked.

resource function get hello() {
    //... GET request is allowed
}

resource function 'default hello() {
    //... Any request excepts for GET is allowed.
}

In this instance, other could be a possible suggestion for the accessor. Any is also possible when the user is aware of the dispatching logic rule (The most specific HTTP method is allowed).

[Maninda]

When we use default it is not obvious that all the HTTP accessors are included.
Instead, we can use any or all.
As any is relevant to the any data type, that may be bit ambiguous. But in the context of an accessor, we can consider any as the universal accessor like we use any for universal type.
When we want to use a proper subset of the accessors (for e.g.: GET and POST only) may be we can use a syntax like get|post as we use for data types.

[chamil321]

Agree with the first point where default does not sound that it allows all HTTP methods including custom methods.

The second option which to use the union type is restricted by the design intentionally. So that the user won't use unmatching methods within the same resource. For example, POST and GET in the same resource does not make sense as the logic should be different. i.e getter and setter