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 <[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/
