Hi Syncoper, here are the proposed changes for our Configuration Service:
* Changing Create response type to javax.ws.rs.core.Response. This way we can set response HTTP Status code (201 created) without requiring HttpServletResponse as method parameter. Also according to best RESTful practices instead of returning newly created object directly, only URL for new Object (Configuration) will be returned. Console does not even care about created response, thus network traffic can be reduced, by not sending object (configuration). If consumer does care about new object he can easily follow provided URL (in response) and retrieve new object. * Changed ModelAndView response type to Set<ValidatorTO> / Set<MailTemplateTO> and introduced wrapper TO classes for ValidatorTO and MailTemplateTO. * Changed return type from update() and delete() to void, since console does not even care about it, and I think this should be best practice anyway, since consumer knows updates object already and does not care about deleted ones, therefore there is no need to send them over the network. Any objections? Best regards. Jan > -----Original Message----- > From: Jan Bernhardt [mailto:jbernha...@talend.com] > Sent: Donnerstag, 17. Januar 2013 14:04 > To: dev@syncope.apache.org > Subject: RE: [Discussion] New REST Service Interfaces - Entitlements > > Hi Syncoper, > > The following changes are proposed regarding AuthenticationController: > > === Renaming Service === > Rename AuthenticationController to EntitlementService(Impl), since > containing methods have little to nothing to do with authentication. It is > only > about Entitlements... > > === Changing response Type === > listEntitlements() returns a List<String> whereas getEntitlements() returns a > Set<String>. > > From my point of view both methods should return a SET since entitlements > have no order and cannot exists or be assigned more than once. > > Due to some JAX-B / JAX-RS limitations, it is not possible to return a > collection > with primitive data types in java. A wrapper class is required, e.g. > Set<EntitlementTO>. > > EntitlementTO can be modeled in one of two ways: > > Option 1: > <EntitlementTOs> > <EntitlementTO>ROLE_ADMIN</EntitlementTO> > <EntitlementTO>ROLE_SUPERUSER</EntitlementTO> > </EntitlementTOs> > > Option 2: > <EntitlementTOs> > <EntitlementTO> > <name>ROLE_ADMIN</name> > </EntitlementTO> > <EntitlementTO> > <name> ROLE_SUPERUSER </name> > </EntitlementTO> > </EntitlementTOs> > > Option 1 matches more or less current marshaling. I personally would prefer > Option 2 because this would give us the opportunity to easily extend > EntitlementTO at a later point (if needed) without becoming incompatible > with previous version. > > WDYT? > > All of these changes will not apply to current Spring Controller/Services, but > only future CXF REST Service. So AuthenticationController will not be > renamed now, and responsetype of AuthenticationController will not > change. Changes only apply for new Service Interface and (Proxy) > Implementation. > > Best regards. > Jan
