incubator-syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: REST Controller consistency
Date Fri, 13 Apr 2012 16:47:56 GMT
Hi Francesco,

I've tried to go the reg-exp route, e.g.:

 @RequestMapping(method = RequestMethod.GET, value =
"/deleteByUsername/{username:.*}")
    public UserTO delete(@PathVariable final String username)

The username String gets picked up correctly
("delete.by.username@apache.org"). However, I see another error in the
logs:

SEVERE: Servlet.service() for servlet [syncope-core-rest] in context
with path [/syncope] threw exception [Could not resolve view with name
'user/deleteByUsername/delete.by.username@apache' in servlet with name
'syncope-core-rest'] with root cause
javax.servlet.ServletException: Could not resolve view with name
'user/deleteByUsername/delete.by.username@apache' in servlet with name
'syncope-core-rest'

Any ideas?

Colm.

2012/4/6 Francesco Chicchiriccò <ilgrosso@apache.org>:
> On 05/04/2012 17:44, Colm O hEigeartaigh wrote:
>> Actually I've run into a problem when using
>> "/deleteByUsername/{username}", where "username" is an email-address.
>> Spring is truncating the @PathVariable and removing the ".org" at the
>> end of the email address. Any ideas? I tried setting
>> "useDefaultSuffixPattern" to false in the
>> DefaultAnnotationHandlerMapping object defined in restContext.xml, but
>> this seemed to cause other problems.
>
> Yes, because Syncope empowers ".json" and ".xml" Spring views.
>
> What do you think about the regexp solution proposed at
> http://stackoverflow.com/questions/3526523/spring-mvc-pathvariable-getting-truncated
> ?
>
> Cheers.
>
>> On Thu, Apr 5, 2012 at 3:24 PM, Colm O hEigeartaigh <coheigea@apache.org> wrote:
>>> Hi Francesco,
>>>
>>>> /read/{userId}
>>>> /readByUsername/{username}
>>>> /delete/{userId}
>>>> /deleteByUsername/{username}
>>> Makes sense - I'll follow your suggestion.
>>>
>>> Colm.
>>>
>>> 2012/4/4 Francesco Chicchiriccò <ilgrosso@apache.org>:
>>>> On 04/04/2012 15:27, Colm O hEigeartaigh wrote:
>>>>> Hi,
>>>>>
>>>>> There is an inconsistency in the REST API as discussed on Syncope-42.
>>>>> For example, both read and delete follow the same pattern for userIds
>>>>> and usernames:
>>>>>
>>>>>  - /read/{userId}
>>>>>  - /read?username=X
>>>>>
>>>>> Francesco suggested the following:
>>>>>
>>>>>
>>>>> https://issues.apache.org/jira/browse/SYNCOPE-42?focusedCommentId=13245457&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13245457
>>>>>
>>>>> However, the first approach does not seem to work, as he suspected.
>>>>> However, if we move to the latter suggestion, this will cause
>>>>> additional inconsistencies with other methods, such as
>>>>> "user/reactivate/{userId}".
>>>>>
>>>>> /read?userId={userId}
>>>>> /read?username={username}
>>>>> /delete?userId={userId}
>>>>> /delete?username={username}
>>>>>
>>>>> Any suggestions on the best way to proceed?
>>>>
>>>> Hi Colm,
>>>> moving everything to the "request parameter" way (i.e. the latter above)
can
>>>> have some unexpected side effects on the other 16 REST controllers (besides
>>>> UserController).
>>>>
>>>> I mean, if we decide to change /read/{userId} to /read?userId={userId}, we
>>>> will end up by changing also /read/{notificationId} and so on.
>>>>
>>>> From the other side, keeping the situation as is for UserController leads
to
>>>> an unacceptable inconsistency, as pointed out by you: hence my proposal is
>>>> to have:
>>>>
>>>> /read/{userId}
>>>> /readByUsername/{username}
>>>> /delete/{userId}
>>>> /deleteByUsername/{username}
>>>>
>>>>
>>>> We can do the same duplication for each REST method taking {userId} as
>>>> parameter.
>>>>
>>>> All this situation only affects UserController, since SyncopeUser is the
>>>> only entity having a primary key (Long id) and a field with UNIQUE NOT NULL
>>>> constraint (String username).
>>>>
>>>> Regards.
> --
> Francesco Chicchiriccò
>
> Apache Cocoon PMC and Apache Syncope PPMC Member
> http://people.apache.org/~ilgrosso/
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Mime
View raw message