Web Services: REST calls by username instead of userID

score 10
Voted on 2 times. You have not voted. Delivered

After a call we had, I'd like to raise the dialogue on how the web services are implemented.  Mainly, I am asking that in the upcoming design sessions you revisit the way the REST service calls are referenced.


Here's our issue/use case:  We are trying to integrate Tivoli ITIM into the web services side of Jive 5 to automatically deactivate and reactivate users as their corporate status changes.  In order to deactivate a user via the REST web service, you need to specify that user by the *internal to Jive* user ID number.  We have no datastore on our side to know what that number is, which breaks the design pattern for SOA (common keys).  To obtain that internal ID number we have to use the legacy web service lookup by username, which returns an object we then must parse to grab the userID, and then return that to the REST call.  I understand that in Jive 6 the legacy webservices are being deprecated, so this will become increasingly important.  I humbly ask that you consider including REST services that can be called by username, as that is the key point of data that is exchanged between systems, whether SSO federation, LDAP sync, etc.


Also, returning some XML with a successful disableUser call rather than an empty body with just a 200 OK in the header would be helpful in doing client-side processing.





Vote history