The final clarification from my end,
in the below example,
GET /service/all/1
PUT /service/all/1
PUT /service
matches nothing.
Thanks, Sergey
On 23/01/15 15:37, Sergey Beryozkin wrote:
> Hi Bill,
>
> @DefaultMethod is not an option for dealing with failed matches.
> It is just a verb method wildcard. Nothing would change in the algorithm
> apart from the few clarifications on the filtering.
>
> IMHO it just adds much more confusion to the discussion, talking about
> all the match issues in context of this discussion. I'm fine with you
> exploring the options to improve but please do use another thread for it
> :-)
>
> Here is the example from a test I did to our code:
>
> @Path("service")
> public class DefaultMethodResource {
>
> @Path("all")
> @DefaultMethod
> public Response all() {
> return null;
> }
> @Path("all")
> @GET
> public Response getAll() {
> return null;
> }
> @GET
> public Response get() {
> return null;
> }
> }
>
> PUT /service/all -> all()
> GET /service/all -> getAll()
> GET /service -> get()
>
> Nothing new. Just an optional method wild-card support.
>
> I'm fine to be honest with it either to be accepted or not, I just need
> this extension fr my own work either way, so I'm proceeding :-)
>
> Sergey
>
>
> On 23/01/15 15:00, Santiago Pericas-Geertsen wrote:
>>
>>> On Jan 23, 2015, at 9:26 AM, Bill Burke <bburke_at_redhat.com
>>> <mailto:bburke_at_redhat.com>> wrote:
>>>
>>>
>>>
>>> On 1/23/2015 8:13 AM, Santiago Pericas-Geertsen wrote:
>>>>
>>>>> On Jan 22, 2015, at 5:27 PM, Bill Burke <bburke_at_redhat.com
>>>>> <mailto:bburke_at_redhat.com>> wrote:
>>>>>
>>>>> Markus, maybe we're both confused on what exactly is being suggested
>>>>> here. Thought I already stated my counterproposal:
>>>>>
>>>>> Fix the matching algorithm to support backtracking. Then, for
>>>>> example, if you want to provide default OPTIONS support you just
>>>>> define a resource class, subrsource class, and/or resource method to
>>>>> do that. Its what we supported for years and years until the TCK got
>>>>> strict. If you want to avoid typos for wildcards, add a constant to
>>>>> @Path
>>>>>
>>>>> static final string WILDCARD = "{wildcard:.*}”;
>>>>
>>>> I believe what Sergey is proposing is to add a default method to a
>>>> path that already matches, which is slightly different (and much
>>>> simpler) than matching on all paths and using backtracking to get
>>>> there. The application code will look very different.
>>>>
>>>> As for backtracking, I believe we already had this discussion; the
>>>> formalization of a backtracking algorithm has a lot of little details
>>>> that need to be worked out to ensure compatibility, most notably, the
>>>> ordering in which the different alternatives are tried when
>>>> backtracking.
>>>>
>>>> We have had the users' alias open for years, and I don’t recall any
>>>> requests about this. So, although I can see some users benefiting
>>>> from backtracking, I’m not convinced this represents a significant
>>>> portion of the developer community as you seem to imply.
>>>>
>>>
>>> You can't say that you're not convinced backtracking effects a
>>> significant portion of the dev community, then support adding
>>> something like @DefaultMethod which also doesn't effect a significant
>>> portion of the dev community.
>>
>> I’m on the fence with @DefaultMethod, but it’s worth exploring. And,
>> yes, I can support one and not the other because the cost-benefit of
>> @DefaultMethod seems far better.
>>
>>> Even with the proposed @DefaultMethod, you'd have add a @DefaultMethod
>>> method to every single resource class where you wanted to handle
>>> default beahvior.
>> No, as I see it this use case is the exception, not the rule. If most
>> users would need to add @DefaultMethod on most resource classes,
>> something different would be need it.
>>
>> — Santiago
>>
>