Hi Jan
On 23/01/13 08:06, Jan Bernhardt wrote:
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.
I think it is fine echoing back the created resource representation
(alongside Location) when it can help the client to avoid the extra
round trip, I guess it depends on the actual requirements of the console
client
* Changed ModelAndView response type to Set<ValidatorTO> / Set<MailTemplateTO>
and introduced wrapper TO classes for ValidatorTO and MailTemplateTO.
One thing I should mention is that auto-describing the explicit
collections is tricky in WADL, though of course one can register a
custom WADL document with CXF; personally I prefer using collection
wrapper beans - it is simpler to get them described and also easier to
attach some more metadata to such collection in the form of the wrapper
properties, that said, returning the explicit collections will also work
Cheers, Sergey
* 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
