----- Original message -----
From: Pavel Bucek <pavel.bucek@oracle.com>
To: users@jax-rs-spec.java.net
Cc:
Subject: [jax-rs-spec users] Re: Native support for additional HTTP methods
Date: Wed, Apr 5, 2017 9:59 AM
Trace already is supported in the Client API, see https://github.com/jax-rs/api/blob/master/jaxrs-api/src/main/java/javax/ws/rs/client/SyncInvoker.java#L341
CONNECT would be different story. Client does connect when using PROXY to access the server resource, but the implications of supporting that in the API are not trivial. CONNECT X usually follows with some response and the same connection then must be used to send another HTTP request. Since JAX-RS Client doesn't have any notion of state or a connection and it would be non-trivial to add. (Not to mention that we don't really want to do it).
But I didn't say that to discourage you - if you have a use case which would fit and be reasonable to have in REST client, please share it.
Thanks and regards,
Pavel
On 05/04/2017 16:15, Andrew McCright wrote:Thanks Pavel, PATCH is the one I'm most interested in as well.As for CONNECT and TRACE, I agree that they don't make as much sense for the server, but what about adding methods for them in the Client API? Even if not in a truly RESTful context, many users find the JAX-RS Client API to be preferable to other APIs like HttpClient because the API is very easy and it comes "out of the box" from EE servers.Thanks again,----- Original message -----
From: Pavel Bucek <pavel.bucek@oracle.com>
To: users@jax-rs-spec.java.net
Cc:
Subject: [jax-rs-spec users] Re: Native support for additional HTTP methods
Date: Wed, Apr 5, 2017 7:21 AM
Hi Andrew,
I added 2.1-candidate tag to an issue which suggests adding PATCH method and content type.
I'm not exactly sure how should an application handle TRACE request - isn't that something which should be handled by the underlying container?
CONNECT is similar - what would be the usecase of handing that from JAX-RS application? (I believe I'm not the only one who is not considering implementing HTTP proxy as a valid usecase for REST API to support).
Thanks and regards,
PavelOn 04/04/2017 22:32, Andrew McCright wrote:
Hi All,We've seen a number of requests from our customers for built-in support of other HTTP methods such as CONNECT, TRACE, and PATCH -- PATCH has been especially requested.While it is currently possible for users to define their own custom HTTP methods, I've seen a few support cases where users are not implementing them properly - for example, one customer did not safely implement a PATCH method for case sensitivity, so when a client sent a "patch" request, they ended up with a 415.What would you think about adding these methods as annotations in the spec?Thanks,Andy