Support response body negotiation for PUT and POST requests via Accept header [DATAREST-34]

[spring-projects-issues]

Oliver Drotbohm opened DATAREST-34 and commented

Currently the decision whether to render a response body for PUT and POST requests must not be controlled via a request parameter. According to the HTTP spec, representation negotiations have to be done via media types and request/response headers.

I suggest to inspect the Accept header on PUT and POST requests and not render anything if not present (which should be the default)

---

Affects: 1.0.0.RC1

Referenced from: pull request #167, and commits 5486712, f3c74ac

[spring-projects-issues]

Jon Brisbin commented

Adding "returnBody=true" is the way Riak works on PUT/POST, so this functionality is inspired by that. It's also more convenient to use from an Ajax perspective because it's generally more difficult to set custom HTTP headers in ajax libraries than it is to use query parameters.

I'm not sure having a switch for turning on or off returning a body in the response is really content negotiation in the same sense as it's meant to do Accept header based content negotiation. It's simply saying whether or not to return anything after the operation is complete. It's not telling it what to return as that's still being negotiated in the proper place

[spring-projects-issues]

Jeremy Rickard commented

If this is still a desired enhancement (it's been around for a while), I implemented a solution and relevant tests and can submit a pull request.

[spring-projects-issues]

Oliver Drotbohm commented

That ticket seems to be a very old one and - as far as I know - is not really relevant anymore. There's not request parameter anymore and whether a body is returned for PUT and POST is controlled by RepositoryRestConfig.setReturnBodyOnCreate(…) and ….setReturnBodyOnUpdate(…).

So what is it that you actually have implemented?

[spring-projects-issues]

Jeremy Rickard commented

I noticed the date on it was quite old and the request parameter had been replaced with the two RepositoryRestConfig methods, but the ticket was still Open so I wasn't sure if there was still a desire to control it based on the Accept header. I made the determination based on the presence of the Accept header instead of the RepositoryRestConfig.

I like the project a lot so I was mostly just looking for small changes that would let me contribute and understand the internals more. I'll look for something else since this one isn't relevant anymore. Thanks for responding!

[spring-projects-issues]

Oliver Drotbohm commented

I see, I wouldn't mind seeing that improvement (consideration of the Accept header). I think I just got misled by the focus on the request parameter in the title. I think we can use the presence of the accept header as indicator unless the configuration flags are explicitly set to true. Might even be worth exploring to change the flags to Boolean and use a null value to indicate one wants to get the Accept header considered (i.e. not expressing a strong preference for return body styles).

Feel free to submit something :)

[spring-projects-issues]

Oliver Drotbohm commented

Applied with a few changes. But in master, give it a spin