Il giorno 23/gen/2013, alle ore 10.39, Jan Bernhardt ha scritto:
>> -----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.
ok for me
>
> Best regards.
> Jan
>
>>
>>> Regards.
>>>
>>> --
>>> Francesco Chicchiriccò
>>>
>>> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
>>> http://people.apache.org/~ilgrosso/
>>>
>
