Topics

PATCH support on the client


Pavel Bucek
 

Dear experts,

we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method.

I know that we already had a discussion about this, but we concluded that requiring something without having support from the target JDK might be too cumbersome for some environments.

This wouldn't change anything on the server side, it's purely about the client (reflecting the issues related to HttpUrlConnection and derived implementations).

Any comments/suggestions welcomed.

Thanks,
Pavel


 

My opinion is that either we support it completely or not at all. Making it optional renders the feature useless for ISVs: If I cannot rely on it being there on _all_ platforms, I will _never_ use it, or I will _always_ bring it with me on my own. So it would be good for nothing.
-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Montag, 29. Mai 2017 17:23
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] PATCH support on the client

Dear experts,

we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method.

I know that we already had a discussion about this, but we concluded that requiring something without having support from the target JDK might be too cumbersome for some environments.

This wouldn't change anything on the server side, it's purely about the client (reflecting the issues related to HttpUrlConnection and derived implementations).

Any comments/suggestions welcomed.

Thanks,
Pavel


Sergey Beryozkin
 

The issue applies not only to PATCH but to all other methods which happen not be known to HttpUrlConnection.
But rather than say something along the lines "only well-known verbs" can be supported and be forever restricted by this strange HttpUrlConnection restriction given that all stacks can work with HttpClient, I'd rather have JAX-RS 2.1 be much more open.

Even Collection API in java.util. has a number of optional methods. Some ISVs might decide not to use this optional method and use their own code - but that won't make their code any more portable as it will be tied to HttpClient or similar....


Sergey

On 29/05/17 17:19, Markus KARG wrote:
My opinion is that either we support it completely or not at all. Making it optional renders the feature useless for ISVs: If I cannot rely on it being there on _all_ platforms, I will _never_ use it, or I will _always_ bring it with me on my own. So it would be good for nothing.
-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Montag, 29. Mai 2017 17:23
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] PATCH support on the client

Dear experts,

we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method.

I know that we already had a discussion about this, but we concluded that requiring something without having support from the target JDK might be too cumbersome for some environments.

This wouldn't change anything on the server side, it's purely about the client (reflecting the issues related to HttpUrlConnection and derived implementations).

Any comments/suggestions welcomed.

Thanks,
Pavel







 

In fact no ISV is using that optional methods unless they package their app with a particular JRE.
-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Sergey Beryozkin
Sent: Montag, 29. Mai 2017 18:29
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] PATCH support on the client

The issue applies not only to PATCH but to all other methods which happen not be known to HttpUrlConnection.
But rather than say something along the lines "only well-known verbs"
can be supported and be forever restricted by this strange HttpUrlConnection restriction given that all stacks can work with HttpClient, I'd rather have JAX-RS 2.1 be much more open.

Even Collection API in java.util. has a number of optional methods.
Some ISVs might decide not to use this optional method and use their own code - but that won't make their code any more portable as it will be tied to HttpClient or similar....


Sergey
On 29/05/17 17:19, Markus KARG wrote:
My opinion is that either we support it completely or not at all. Making it optional renders the feature useless for ISVs: If I cannot rely on it being there on _all_ platforms, I will _never_ use it, or I will _always_ bring it with me on my own. So it would be good for nothing.
-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io]
On Behalf Of Pavel Bucek
Sent: Montag, 29. Mai 2017 17:23
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] PATCH support on the client

Dear experts,

we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method.

I know that we already had a discussion about this, but we concluded that requiring something without having support from the target JDK might be too cumbersome for some environments.

This wouldn't change anything on the server side, it's purely about the client (reflecting the issues related to HttpUrlConnection and derived implementations).

Any comments/suggestions welcomed.

Thanks,
Pavel








Pavel Bucek
 

The issue with Sync/Async/RxInvoker#patch methods is similar to what we do have with Sync/Async/RxInvoker#method, but surprisingly #method doesn't mention anything about unsupported HTTP methods or runtime requirements. On the other hand, there seem to be general agreement about the existence of unsupported HTTP methods.

The problem with #patch is that it is extracted (similarly as #get, #post, ..), so anyone would assume that it has to work.

If there is a strong opposition to marking those methods as optional, we can remove them completely, as suggested. #method is always there, so the functionality is not gone and it might make more sense from certain point of view.

Seems like Markus already stated, that he strongly prefers to remove #patch (compared to keeping them as optional), Sergey might be ok with #patch staying int the client API (feel free to correct me). Any other opinions?

(note that removing methods from the API is simple; we certainly can choose to re-add them later. We also could only lift the "optionality" and creating less disturbing change in the future).

Thanks,
Pavel

On 29/05/2017 18:28, Sergey Beryozkin wrote:
The issue applies not only to PATCH but to all other methods which happen not be known to HttpUrlConnection.
But rather than say something along the lines "only well-known verbs" can be supported and be forever restricted by this strange HttpUrlConnection restriction given that all stacks can work with HttpClient, I'd rather have JAX-RS 2.1 be much more open.

Even Collection API in java.util. has a number of optional methods. Some ISVs might decide not to use this optional method and use their own code - but that won't make their code any more portable as it will be tied to HttpClient or similar....


Sergey
On 29/05/17 17:19, Markus KARG wrote:
My opinion is that either we support it completely or not at all. Making it optional renders the feature useless for ISVs: If I cannot rely on it being there on _all_ platforms, I will _never_ use it, or I will _always_ bring it with me on my own. So it would be good for nothing.
-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Montag, 29. Mai 2017 17:23
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] PATCH support on the client

Dear experts,

we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method.

I know that we already had a discussion about this, but we concluded that requiring something without having support from the target JDK might be too cumbersome for some environments.

This wouldn't change anything on the server side, it's purely about the client (reflecting the issues related to HttpUrlConnection and derived implementations).

Any comments/suggestions welcomed.

Thanks,
Pavel









Sergey Beryozkin
 

Hi Pavel

Right, that what I was also implying, that API already allows to use any HTTP method names, so it is not only about PATCH.
So we should have method(String) variations docs updated.

Re patch() - I've no strong opinion whether this actual method stays or not, because we still have method(), and that was my point when I replied to Markus,
we can/should not enforce an 'either works for all the platform or not at all' solution. Having patch() staying won't change anything except for having this optional method be more visible which is what I guess adding this method was mainly about. If dropping it will make API less controversial then it is fine...

Thanks, Sergey

On 30/05/17 09:13, Pavel Bucek wrote:
The issue with Sync/Async/RxInvoker#patch methods is similar to what we do have with Sync/Async/RxInvoker#method, but surprisingly #method doesn't mention anything about unsupported HTTP methods or runtime requirements. On the other hand, there seem to be general agreement about the existence of unsupported HTTP methods.

The problem with #patch is that it is extracted (similarly as #get, #post, ..), so anyone would assume that it has to work.

If there is a strong opposition to marking those methods as optional, we can remove them completely, as suggested. #method is always there, so the functionality is not gone and it might make more sense from certain point of view.

Seems like Markus already stated, that he strongly prefers to remove #patch (compared to keeping them as optional), Sergey might be ok with #patch staying int the client API (feel free to correct me). Any other opinions?

(note that removing methods from the API is simple; we certainly can choose to re-add them later. We also could only lift the "optionality" and creating less disturbing change in the future).

Thanks,
Pavel



On 29/05/2017 18:28, Sergey Beryozkin wrote:
The issue applies not only to PATCH but to all other methods which happen not be known to HttpUrlConnection.
But rather than say something along the lines "only well-known verbs" can be supported and be forever restricted by this strange HttpUrlConnection restriction given that all stacks can work with HttpClient, I'd rather have JAX-RS 2.1 be much more open.

Even Collection API in java.util. has a number of optional methods. Some ISVs might decide not to use this optional method and use their own code - but that won't make their code any more portable as it will be tied to HttpClient or similar....


Sergey
On 29/05/17 17:19, Markus KARG wrote:
My opinion is that either we support it completely or not at all. Making it optional renders the feature useless for ISVs: If I cannot rely on it being there on _all_ platforms, I will _never_ use it, or I will _always_ bring it with me on my own. So it would be good for nothing.
-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Montag, 29. Mai 2017 17:23
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] PATCH support on the client

Dear experts,

we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method.

I know that we already had a discussion about this, but we concluded that requiring something without having support from the target JDK might be too cumbersome for some environments.

This wouldn't change anything on the server side, it's purely about the client (reflecting the issues related to HttpUrlConnection and derived implementations).

Any comments/suggestions welcomed.

Thanks,
Pavel











Alessio Soldano
 

Il 30/05/2017 10:48, Sergey Beryozkin ha scritto:
Re patch() - I've no strong opinion whether this actual method stays or not, because we still have method(), and that was my point when I replied to Markus,
we can/should not enforce an 'either works for all the platform or not at all' solution. Having patch() staying won't change anything except for having this optional method be more visible which is what I guess adding this method was mainly about. If dropping it will make API less controversial then it is fine...
Same feeling here.

Cheers
Alessio


Thanks, Sergey

On 30/05/17 09:13, Pavel Bucek wrote:
The issue with Sync/Async/RxInvoker#patch methods is similar to what we do have with Sync/Async/RxInvoker#method, but surprisingly #method doesn't mention anything about unsupported HTTP methods or runtime requirements. On the other hand, there seem to be general agreement about the existence of unsupported HTTP methods.

The problem with #patch is that it is extracted (similarly as #get, #post, ..), so anyone would assume that it has to work.

If there is a strong opposition to marking those methods as optional, we can remove them completely, as suggested. #method is always there, so the functionality is not gone and it might make more sense from certain point of view.

Seems like Markus already stated, that he strongly prefers to remove #patch (compared to keeping them as optional), Sergey might be ok with #patch staying int the client API (feel free to correct me). Any other opinions?

(note that removing methods from the API is simple; we certainly can choose to re-add them later. We also could only lift the "optionality" and creating less disturbing change in the future).

Thanks,
Pavel



On 29/05/2017 18:28, Sergey Beryozkin wrote:
The issue applies not only to PATCH but to all other methods which happen not be known to HttpUrlConnection.
But rather than say something along the lines "only well-known verbs" can be supported and be forever restricted by this strange HttpUrlConnection restriction given that all stacks can work with HttpClient, I'd rather have JAX-RS 2.1 be much more open.

Even Collection API in java.util. has a number of optional methods. Some ISVs might decide not to use this optional method and use their own code - but that won't make their code any more portable as it will be tied to HttpClient or similar....


Sergey
On 29/05/17 17:19, Markus KARG wrote:
My opinion is that either we support it completely or not at all. Making it optional renders the feature useless for ISVs: If I cannot rely on it being there on _all_ platforms, I will _never_ use it, or I will _always_ bring it with me on my own. So it would be good for nothing.
-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Montag, 29. Mai 2017 17:23
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] PATCH support on the client

Dear experts,

we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method.

I know that we already had a discussion about this, but we concluded that requiring something without having support from the target JDK might be too cumbersome for some environments.

This wouldn't change anything on the server side, it's purely about the client (reflecting the issues related to HttpUrlConnection and derived implementations).

Any comments/suggestions welcomed.

Thanks,
Pavel













Andy McCright
 

That is more-or-less my opinion too.  I'd prefer that we supported the patch() method fully (not optionally), but if the decision is support it optionally or not at all, I'd choose not at all.
 
On this topic, is it possible to remove the HttpUrlConnection restriction in Java 9 so that we could have more flexibility for future JAX-RS Client APIs?
 
Thanks,
 
Andy


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 

----- Original message -----
From: "Alessio Soldano" <asoldano@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] PATCH support on the client
Date: Tue, May 30, 2017 6:42 AM
 
Il 30/05/2017 10:48, Sergey Beryozkin ha scritto:
> Re patch() - I've no strong opinion whether this actual method stays
> or not, because we still have method(), and that was my point when I
> replied to Markus,
> we can/should not enforce an 'either works for all the platform or not
> at all' solution. Having patch() staying won't change anything except
> for having this optional method be more visible which is what I guess
> adding this method was mainly about. If dropping it will make API less
> controversial then it is fine...
Same feeling here.

Cheers
Alessio

>
> Thanks, Sergey
>
> On 30/05/17 09:13, Pavel Bucek wrote:
>> The issue with Sync/Async/RxInvoker#patch methods is similar to what
>> we do have with Sync/Async/RxInvoker#method, but surprisingly #method
>> doesn't mention anything about unsupported HTTP methods or runtime
>> requirements. On the other hand, there seem to be general agreement
>> about the existence of unsupported HTTP methods.
>>
>> The problem with #patch is that it is extracted (similarly as #get,
>> #post, ..), so anyone would assume that it has to work.
>>
>> If there is a strong opposition to marking those methods as optional,
>> we can remove them completely, as suggested. #method is always there,
>> so the functionality is not gone and it might make more sense from
>> certain point of view.
>>
>> Seems like Markus already stated, that he strongly prefers to remove
>> #patch (compared to keeping them as optional), Sergey might be ok
>> with #patch staying int the client API (feel free to correct me). Any
>> other opinions?
>>
>> (note that removing methods from the API is simple; we certainly can
>> choose to re-add them later. We also could only lift the
>> "optionality" and creating less disturbing change in the future).
>>
>> Thanks,
>> Pavel
>>
>>
>>
>> On 29/05/2017 18:28, Sergey Beryozkin wrote:
>>> The issue applies not only to PATCH but to all other methods which
>>> happen not be known to HttpUrlConnection.
>>> But rather than say something along the lines "only well-known
>>> verbs" can be supported and be forever restricted by this strange
>>> HttpUrlConnection restriction given that all stacks can work with
>>> HttpClient, I'd rather have JAX-RS 2.1 be much more open.
>>>
>>> Even Collection API in java.util. has a number of optional methods.  
>>> Some ISVs might decide not to use this optional method and use their
>>> own code - but that won't make their code any more portable as it
>>> will be tied to HttpClient or similar....
>>>
>>>
>>> Sergey
>>> On 29/05/17 17:19, Markus KARG wrote:
>>>> My opinion is that either we support it completely or not at all.
>>>> Making it optional renders the feature useless for ISVs: If I
>>>> cannot rely on it being there on _all_ platforms, I will _never_
>>>> use it, or I will _always_ bring it with me on my own. So it would
>>>> be good for nothing.
>>>> -Markus
>>>>
>>>> -----Original Message-----
>>>> From: jaxrs-spec@javaee.groups.io
>>>> [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
>>>> Sent: Montag, 29. Mai 2017 17:23
>>>> To: jaxrs-spec@javaee.groups.io
>>>> Subject: [jaxrs] PATCH support on the client
>>>>
>>>> Dear experts,
>>>>
>>>> we'd like to make the HTTP PATCH support on the client optional,
>>>> throwing UnsupportedOperationException on client runtimes, which
>>>> don't support that method.
>>>>
>>>> I know that we already had a discussion about this, but we
>>>> concluded that requiring something without having support from the
>>>> target JDK might be too cumbersome for some environments.
>>>>
>>>> This wouldn't change anything on the server side, it's purely about
>>>> the client (reflecting the issues related to HttpUrlConnection and
>>>> derived implementations).
>>>>
>>>> Any comments/suggestions welcomed.
>>>>
>>>> Thanks,
>>>> Pavel
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>