> +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. 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 > > > >
