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/
