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.Colm. On Thu, Apr 5, 2012 at 3:24 PM, Colm O hEigeartaigh <[email protected]> wrote: > Hi Francesco, > >> /read/{userId} >> /readByUsername/{username} >> /delete/{userId} >> /deleteByUsername/{username} > > Makes sense - I'll follow your suggestion. > > Colm. > > 2012/4/4 Francesco Chicchiriccò <[email protected]>: >> 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 -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
