Jaxrs-api: Inconsistencies in Jax-rs Client Implemenation wenn calling PUT with null value

[rsoika]

I regognized inconsistencies between Jersey and RestEasy implementation of the Jax-RS Client code. The following code does not work in Jersey:

javax.ws.rs.clientClient client;
....
Response response = client.target(uri).request().put(null);

An IllegalStateException is thrown:

java.lang.IllegalStateException: Entity must not be null for http method PUT.
...  |  at org.glassfish.jersey.client.JerseyInvocation.validateHttpMethodAndEntity(JerseyInvocation.java:155)

The same code is accepted by RestEasy.

You may argue that a PUT method without a body does not make sense. But I don't think the jax-rs client implementation should try to educate the developer for good API. In the end, this behavior only limits the client.

And the following jax-rs resource method is valid for both implementations:

@PUT
@Path("/my-resource/{id}")
public Response backup(@PathParam("id") String id, @QueryParam("options") String options) {
      ....
}

Implementing the client code independent form one of these platforms (jersey/resteasy) forces the developer to create a dummy object:

Response response = client.target(uri).request().put(Entity.xml(""));

This call is now valid for both implementations.

I don't know how I can give a wise advice here as I am 'only' developing against the jax-rs api. But it would be great if both implementations have a similar behavior.
Maybe this issue can be fixed in some way for the next version of the spec?

[chkal]

@rsoika Thanks for bringing this up.

I agree that the spec or the API docs should state whether null is allowed for the entity in the PUT case or not. I've mixed feelings about that. On the one hand using PUT without a body doesn't make sense from a semantic perspective. On the other hand I don't think that implementations should explicitly prevent the user from sending such requests.

Other thoughts?

[mkarg]

+1 for allowing null with PUT, as we should not artificially restrict the API. There might be valid use cases, even when we do not know them so far.

[chkal]

I just did a quick Google search and it looks like there are APIs allowing PUT with empty body like the Spotify API for Play/Resume.

Let me emphasize this again: There is no doubt that using PUT in this context is weird from the semantic perspective, but there are APIs out there implemented this way. And currently you cannot use the JAX-RS client API in a portable way to call such APIs.

[spericas]

I agree, I don’t see the value of restricting it at the API level.

— Santiago

On Jun 20, 2018, at 1:24 PM, Markus KARG [e-mail] wrote:

+1 for allowing null with PUT, as we should not artificially restrict the API. There might be valid use cases, even when we do not know them so far.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/eclipse-ee4j/jaxrs-api/issues/632#issuecomment-398830523, or mute the thread https://github.com/notifications/unsubscribe-auth/AFU9N3F_scLI0SuR6PXWyJjCMn4ILPA-ks5t-oVDgaJpZM4UviIs.

[rsoika]

And we must see, that the same api allows the implementation of such kind of resource methods:

@PUT
@Path("/my-resource/{id}")
public Response backup(@PathParam("id") String id, @QueryParam("options") String options) {
      ....
}

Even if this looks weird. I have done this by myself (and I am not proud about it). But so the same api should not avoid me to call the method with its own client.

[jansupol]

This is a discussion that people had about the HTTP 1.1 RFC, I spent some time and there is quite a number of posts saying it's prohibited by the RFC to have an empty entity and there is a number of posts saying that it is (strictly) prohibited not.

Jersey allows to disable the validation by using ClientProperties.SUPPRESS_HTTP_COMPLIANCE_VALIDATION and then PUT null is allowed