@Context injection optional for now. I'll update the spec to indicate that. Thanks for following up on this issue!
@RegisterProvider annotation, but iiuc, you should be able to accomplish the same thing using MP Config - i.e. use a default file location in the code, but lookup the file location using a config property so that you could change the location in different environments (using system properties, env vars, etc.).
@RegisterProvider, which means that ConfigProperty injection would not be available. Basically, Config injection works in any object instance that is managed by CDI.
@andymc12 It would definitely be a big +1 for me. I added an issue in github, maybe it can start the conversation there...
eclipse/microprofile-rest-client#256
🤷♂️
We don't specify @PATCH in the spec or test it in the TCK. That might be something we want to add?
If the implementation is based on Java's HttpURLConnection API, then PATCH requests won't work - the Java implementation only allows HTTP methods that it knows about (GET, POST, PUT, DELETE, HEAD, OPTIONS - a few others, I think), but it doesn't allow PATCH methods...
Implementations could use deep reflection to get around that limitation in the JDK - or use another HTTP Client API, like Apache HTTP Client. Also, I think the Java 11 HTTP Client API does not have this limitation (but of course, that requires Java 11+...).
Glad to hear that you are unstuck - keep in mind that HTTP servers not required to support X-HTTP-Method-Override (though most REST servers do).
You could also use @ClientHeaderParam(name = "X-HTTP-Method-Override", value = "PATCH") on the method and then avoid needing to create a parameter for callers to pass "PATCH" to.
RestClientBuilder-built clients
@Path interface-level annotation on the interface, but I notice in the spec, the @Path isn't included in the interface. Is the intent here that only the implementation would include a class-level @Path and in order to point to the right place, you'd include that path value in your baseUri when constructing the client proxy?
Hi @jwcarman - I work on MP Rest Client and on Open Liberty - I'll reply here with "MP" hat on, and reply in the OL channel with my "OL" hat.
The MP Rest Client spec is really only interested in the client side - or rather providing a client side view of the remote service. Since it is intended to work with any REST service, not necessarily a JAX-RS-based service, we don't require or recommend the pattern of JAX-RS resource classes implementing an interface that can also be re-used as the Rest Client interface - though, I do believe that that is a fairly common pattern.
To ensure portability with this pattern, I think that we would need to change the JAX-RS (now Jakarta RESTful Web Services) spec to allow interface inheritance of annotations.
As you mentioned in the other thread, it is possible to put no annotations on the client interface and define the path using the baseUri when creating the client instance - for example:
@Path("path")
public interface MyClient { //...
}
MyClient client = RestClientBuilder.newBuilder().baseUri("http://myhost:9080/app-path").build(MyClient.class);is effectively the same as:
public interface MyClient { //...
}
MyClient client = RestClientBuilder.newBuilder().baseUri("http://myhost:9080/app-path/path").build(MyClient.class);