[jira] Updated: (WW-3303) allow POST, PUT or DELETE to return content

["Luca Marrocco (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/struts/browse/WW-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luca Marrocco updated WW-3303:
------------------------------

    Attachment: allow-content-for-POST-PUT-DELETE.patch

this patch modify DefaultContentTypeHandlerManager comment out code that avoid not error response (POST, PUT, DELETE) return back a content.

> allow POST, PUT or DELETE to return content
> -------------------------------------------
>
>                 Key: WW-3303
>                 URL: https://issues.apache.org/struts/browse/WW-3303
>             Project: Struts 2
>          Issue Type: Improvement
>          Components: Plugin - REST
>    Affects Versions: 2.2.x
>         Environment: this problem involve any environment
>            Reporter: Luca Marrocco
>            Priority: Minor
>         Attachments: allow-content-for-POST-PUT-DELETE.patch
>
>
> currently return a content from a request using POST, PUT or DELETE method is explicit ignored by DefaultContentTypeHandlerManager:
> // Don't return any content for PUT, DELETE, and POST where there are no errors
> if (!statusNotOk && !"get".equalsIgnoreCase(req.getMethod())) {
>   target = null;
> }
> many time expecially in ajax application that use restful webservice endpoints required that returned content from those request had some information. This help client to reduce the network usage. So the client don't need to do 2 request to update a content and retrive updated content.
> for instance DELETE /items/1 can responde with information usegul to the client:
> { movingTo: "/archived-items/1", status: "archiving" }
> in general would be responsability of protocol implementation chose right content to return back to the client. Or in other world developer need to have freedom to chose to return back a content or not.
> to complete the description of this issue i report here some excerpt of HTTP 1.1 specification where is described that those method request should return a content (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5):
> * POST, "The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK)_ or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result."
> * PUT, rfc do not explicit disallow returning a content
> * DELETE, "A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity. "

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.