We Keep Coding

Is it possible to intercept Java 11 HttpClient requests?

Basically as the title says. Apache HttpClient and Spring RestTemplate allow for defining custom interceptors which wrap around requests/responses and allow for additional (global) modification of request parameters, logging, etc...
I do not see such a feature available in standard Java implementation of java.net.http.HttpClient (as of Java 11). Am I missing something or is there no way to intercept all requests/responses on a single HttpClient?

There isn't a built-in solution, but you can write your own code as in this answer or use this interceptable-http-client library.

difference between jersey Rest apis and org.restlet apis

I am new to rest apis in java.I found ,there are mainly two methods to create Rest Apis in java.One method is using Jersey and other i think is using org.restlet (not sure i mean without jersey).so whats the main difference between these two.

Restlet provides an API to build and consume RESTful applications. It provides a wide support of HTTP headers and mechanisms described in REST. It also comes with a set of pluggable features like:
Content negotiation - support of the Accept* header
Routing - provide a flexible way to build the processing chain (filter, authenticator, server resource)
Authentication - a frame to plug existing scheme for security at the level of the Authorization header
Converter - a frame to integrate entities to serialize / deserialize structured content like JSON, XML, YAML
Connector - a frame to register and use tools (like Jetty) for serving and calling RESTful applications
Jersey is an implementation of the JAXRS specification. You can notice that Restlet also provides an implementation of this specification through its JAXRS extension: https://restlet.com/technical-resources/restlet-framework/guide/2.3/extensions/jaxrs.

I have REST API and want to reuse it for exposing differen format API on same server

I implemented and exposed REST API on my server. Now I need to expose same API, but I can't use REST (it's actually websocket messages), it will be some custom format. Don't ask why )
I imagine message transformation from my custom format to http request, then process it in my web-server, transform response back to my custom format, and send to client.
The simplest way is regular http call to localhost. For example (java):
HttpURLConnection con = (HttpURLConnection) new URL("http://localhost/api/...").openConnection();
and so on, or using some http client library.
But I'm afraid there will be too much overhead, creating connection, etc.
Another ways:
I use Tomcat. Push my request directly to tomcat somehow.
I use Guice, and all requests go through GuiceFilter. Craft ServetRequest, ServletResponce and FilterChain objects and directly call GuiceFilter.doFilter.
I use GuiceContainer for Jersey. Some test frameworks use it for REST API testing, but also need to craft request/response objects.
There is no standard way to craft request object at all.
And I don't know on which level it's better to add my custom requests.
Hope I described my problem clearly.

Atmosphere may be a good fit here. It's allegedly compatible with both Resteasy and Jersey, so that's a plus, it simply adds WebSocket functionality on top of these.
Caveat: I haven't tried this myself, but came across it when looking for the same capability. :-)

From RestFul point of view, is there a big difference using Jersey(jax-rs) and Servlet

I understand web service provides all SOAP,WSDL support, and it stands at a higher level than Servlet.But if I just simply wanted to expose a rest api to allow another application(client) to make a few very easy queries which can be done even via web browser.
eg. http://serverIP/getUserInfo/123
where 123 is like user's id. Let's just assume user info is returned as json.
Questions are:
Is there a big difference between implementing it in Servlet and Jersey?
If the client application is written in .net, does that make any difference?
Is it true that jax-ws allows you to specify the MIME type to be json while servlet's client has to parse the result?
From performance perspective, which one is quicker? I noticed that normally, Jersey is meant not to be deployed on Tomcat while Servlet is.

Is there a big difference between implementing it in Servlet and
Jersey?
Jersey is a framework that makes it a lot easier to write Restfull services. It uses the Servlet API, so it abstracts away a lot of the low level stuff.
You have to write a lot more code doing it using only the Servlet API, and the code has to deal with a lot of low level stuff that you can configure in a declarative way using Jersey.
If the client application is written in .net, does that make any
difference?
No
Is it true that jax-ws allows you to specify the MIME type to be json
while servlet's client has to parse the result?
Jersey lets you declare the mime type using annotations, but that's only for convenience, you still have to parse the incoming payload to check for correct mime type.
From performance perspective, which one is quicker?
Depends if you are able to write a faster implementation than the Jersey team. Jersey use servlets as well.
I noticed that normally, Jersey is meant not to be deployed on Tomcat
while Servlet is.
Tomcat is a servlet container. Jersey uses the servlet API to communicate over HTTP. There are web-frameworks that don't use servlets, for instance Play framework.

What is the difference between SOAP 1.1, SOAP 1.2, HTTP GET & HTTP POST methods for Android?

I am working on a code for SOAP Web services, I would like to know the variations in SOAP 1.1, SOAP 1.2, HTTP GET & HTTP POST methods for Android, and which is the preferred one among them. Please site out a sample of its usage URL or its code.
Thanks

Differences in SOAP versions
Both SOAP Version 1.1 and SOAP Version 1.2 are World Wide Web Consortium (W3C) standards. Web services can be deployed that support not only SOAP 1.1 but also support SOAP 1.2. Some changes from SOAP 1.1 that were made to the SOAP 1.2 specification are significant, while other changes are minor.
The SOAP 1.2 specification introduces several changes to SOAP 1.1. This information is not intended to be an in-depth description of all the new or changed features for SOAP 1.1 and SOAP 1.2. Instead, this information highlights some of the more important differences between the current versions of SOAP.
The changes to the SOAP 1.2 specification that are significant include the following updates:
SOAP 1.1 is based on XML 1.0. SOAP 1.2 is based on XML Information Set (XML Infoset).
The XML information set (infoset) provides a way to describe the XML document with XSD schema. However, the infoset does not necessarily serialize the document with XML 1.0 serialization on which SOAP 1.1 is based.. This new way to describe the XML document helps reveal other serialization formats, such as a binary protocol format. You can use the binary protocol format to compact the message into a compact format, where some of the verbose tagging information might not be required.
In SOAP 1.2 , you can use the specification of a binding to an underlying protocol to determine which XML serialization is used in the underlying protocol data units. The HTTP binding that is specified in SOAP 1.2 - Part 2 uses XML 1.0 as the serialization of the SOAP message infoset.
SOAP 1.2 provides the ability to officially define transport protocols, other than using HTTP, as long as the vendor conforms to the binding framework that is defined in SOAP 1.2. While HTTP is ubiquitous, it is not as reliable as other transports including TCP/IP and MQ.
SOAP 1.2 provides a more specific definition of the SOAP processing model that removes many of the ambiguities that might lead to interoperability errors in the absence of the Web Services-Interoperability (WS-I) profiles. The goal is to significantly reduce the chances of interoperability issues between different vendors that use SOAP 1.2 implementations.
SOAP with Attachments API for Java (SAAJ) can also stand alone as a simple mechanism to issue SOAP requests. A major change to the SAAJ specification is the ability to represent SOAP 1.1 messages and the additional SOAP 1.2 formatted messages. For example, SAAJ Version 1.3 introduces a new set of constants and methods that are more conducive to SOAP 1.2 (such as getRole(), getRelay()) on SOAP header elements. There are also additional methods on the factories for SAAJ to create appropriate SOAP 1.1 or SOAP 1.2 messages.
The XML namespaces for the envelope and encoding schemas have changed for SOAP 1.2. These changes distinguish SOAP processors from SOAP 1.1 and SOAP 1.2 messages and supports changes in the SOAP schema, without affecting existing implementations.
Java Architecture for XML Web Services (JAX-WS) introduces the ability to support both SOAP 1.1 and SOAP 1.2. Because JAX-RPC introduced a requirement to manipulate a SOAP message as it traversed through the run time, there became a need to represent this message in its appropriate SOAP context. In JAX-WS, a number of additional enhancements result from the support for SAAJ 1.3.
There is not difine POST AND GET method for particular android....but all here is differance
GET
The GET method appends name/value pairs to the URL, allowing you to retrieve a resource representation. The big issue with this is that the length of a URL is limited (roughly 3000 char) resulting in data loss should you have to much stuff in the form on your page, so this method only works if there is a small number parameters.
What does this mean for me? Basically this renders the GET method worthless to most developers in most situations. Here is another way of looking at it: the URL could be truncated (and most likely will be give today's data-centric sites) if the form uses a large number of parameters, or if the parameters contain large amounts of data. Also, parameters passed on the URL are visible in the address field of the browser (YIKES!!!) not the best place for any kind of sensitive (or even non-sensitive) data to be shown because you are just begging the curious user to mess with it.
POST
The alternative to the GET method is the POST method. This method packages the name/value pairs inside the body of the HTTP request, which makes for a cleaner URL and imposes no size limitations on the forms output, basically its a no-brainer on which one to use. POST is also more secure but certainly not safe. Although HTTP fully supports CRUD, HTML 4 only supports issuing GET and POST requests through its various elements. This limitation has held Web applications back from making full use of HTTP, and to work around it, most applications overload POST to take care of everything but resource retrieval.
Link to original IBM source

Following document published by W3C also describes the differences between SOAP 1.1 and 1.2:
From SOAP/1.1 to SOAP Version 1.2 in 9
points