> -----Original Message----- > From: Andrei Shakirin [mailto:ashaki...@talend.com] > Sent: Mittwoch, 23. Januar 2013 10:45 > To: dev@syncope.apache.org > Subject: RE: [DISCUSS] New REST Service Interfaces - ConfigurationService > > > +1 > > URL Location in Response header (as usual) and ResourceID (Long or > > String) in HTTP response body. > > I would even put ResourceID to HTTP header as well. > It is relative small and is kind of object metadata - that corresponds HTTP > Header spec.
Agree. > > Cheers, > Andrei. > > > -----Original Message----- > > From: Jan Bernhardt [mailto:jbernha...@talend.com] > > Sent: Mittwoch, 23. Januar 2013 10:41 > > To: dev@syncope.apache.org > > Subject: RE: [DISCUSS] New REST Service Interfaces - > > ConfigurationService > > > > > -----Original Message----- > > > From: Andrei Shakirin [mailto:ashaki...@talend.com] > > > Sent: Mittwoch, 23. Januar 2013 10:38 > > > To: dev@syncope.apache.org > > > Subject: RE: [DISCUSS] New REST Service Interfaces - > > > ConfigurationService > > > > > > Hi, > > > > > > > I generally agree with the concept of returning created with the > > > > location in create methods. The problem is though that our service > > > > interface has no method to get the object based on the location. > > > > > > Pragmatic solution is returning URI as well as business object ID in > > > Response object. > > > In that case we avoid building URI / extracting ID from URI manually. > > > > +1 > > URL Location in Response header (as usual) and ResourceID (Long or > > String) in HTTP response body. > > > > > > > > Cheers, > > > Andrei. > > > > > > > -----Original Message----- > > > > From: Christian Schneider [mailto:cschneider...@gmail.com] On > > > > Behalf Of Christian Schneider > > > > Sent: Mittwoch, 23. Januar 2013 10:01 > > > > To: dev@syncope.apache.org > > > > Subject: Re: [DISCUSS] New REST Service Interfaces - > > > > ConfigurationService > > > > > > > > Hi Jan, > > > > > > > > I generally agree with the concept of returning created with the > > > > location in create methods. The problem is though that our service > > > > interface has no method to get the object based on the location. > > > > So we either have to change our client and interface to work with > > > > resource uris instead of ids or we have to return the id of the > > > > object in the create method. So perhaps we can return the location > > > > for true restful clients and the id in the entity of the response > > > > for people using the > > > interface. > > > > > > > > Christian > > > > > > > > > > > > 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. > > > > > > > > > > * 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 > > > > >
