> -----Original Message----- > From: Fabio Martelli [mailto:fabio.marte...@gmail.com] > Sent: Mittwoch, 23. Januar 2013 10:29 > To: dev@syncope.apache.org > Subject: Re: [DISCUSS] New REST Service Interfaces - ConfigurationService > > > Il giorno 23/gen/2013, alle ore 09.54, Francesco Chicchiriccò ha scritto: > > > On 23/01/2013 09: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. > > > > If this is a REST best practice, fine for me. > > > >> * Changed ModelAndView response type to Set<ValidatorTO> / > Set<MailTemplateTO> and introduced wrapper TO classes for ValidatorTO > and MailTemplateTO. > > > > Fine. > > > >> * 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. > > > > About update() I can agree with you: since the updated entity (user, role, > ...) is still there, an URL can be returned as in the create() case reported > above.
Technically it would be no problem to return such a URL, but I don't see much value in doing this. Update operations are performed with a PUT Operation. You can use the same URL with a GET Operation to retrieve updated object. This behavior has changed to URL pattern of Spring REST services, where there was a */read/* and */update/* path. With CXF Services I focused on using matching HTTP operations as this also applies to RESTful best practices. > > > > About delete() however, not retuning the deleted entity can break the > current feature: once again, please don't think that the admin console is the > only REST client out there. Old (Spring) REST API will not be changed. New CXF URLs in most cases will not match old URLs (see read, update, delete behavior mentioned above), so clients would have to be updated anyway. And I don't see a problem for a client to first make a GET call an a resource and then following a DELETE call, if he is interested in deleted resource. (which I expect not to be the case most often). > > +1 > The response provided by the delete is also used to know the outcome of > the deletion performed onto the external resources. I agree with you for Roles and Users since changes will be propagated to other systems. But all other resources in Syncope are only internal in Core. Therefore I would suggest to not return anything for delete operation except for users and roles. Best regards. Jan > > > Regards. > > > > -- > > Francesco Chicchiriccò > > > > ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member > > http://people.apache.org/~ilgrosso/ > >
