We Keep Coding

Returning http response from vendor API to a client without any manipulation in REST API

I have a use-case where A calls B, and B calls C via REST APIs(A->B->C). B is a thin orchestrator where the sole responsibility is to route request to C and sends back response from C to A as it is.
I tried to send back the http response from C to A as it is without any manipulation, by completely avoid constructing response(jax-rs)in system B.
The issue is that response received at A does neither have any data or response body nor headers.
Questions & Clarifications :
Are the scope of http request and response specific to each http call?
What is the solution ?

How to make REST call asynchronous in Java

I have REST calls between two microservices, one of the call is taking more than 15 mins of time to complete. We have company's own private cloud implementation which is terminating any open connection kept for more than 15 mins.
We are looking for some asynchronous rest call implementation, where service A will trigger the rest call to service B and forget and service B will notify when the response is ready to be served.
Is there any widely used technique/API for such scenario? I was not able to find any thing concrete on this front.

You could use Polling. Something like this :
Service A triggers a Rest call to Service B which returns an OK response. Then in each 1 minute service A make another API request to another endpoint in Service B which would return status of the previous request until the process is completed or for may be a certain point of time. Now when the 2nd request send the status as success you can mark the process as completed.

Instead of creating the actual resources, create a temporary one. Instead of returning a 201 (Created) HTTP response, you can issue a 202 (Accepted) response code. This informs the client that the request has been accepted and understood by the server, but the resource is not (yet) created. Send the temporary resource inside the Location header.
Request:
POST /blogs HTTP/1.1
<xml>
blogdata
</xml>
Response:
HTTP/1.1 202 Accepted
Location: /queue/12345
This location can store information about the status of the actual resource: an ETA on when it will be created, what is currently being done or processed.
When the actual resource has been created, the temporary resources can return a 303 (See other) response. The location header returns the URI to the definitive resource. A client can either DELETE the temporary resource, or the server can expire this resource and return a 410 (Gone) later on.
Source: https://restcookbook.com/Resources/asynchroneous-operations/

What is the difference between making HttpRequest and Forwarding HttpRequest?

Lets say my client (Browser) request my java service (Service A).
http://localhost:8080/getDataFromB
Based on the request, from my Service A, I need to make another HttpRequest to either Service B or Service C to get the data.
getDataFromB: http://serverb.com/getDataFromB
getDataFromC: http://serverc.com/getDataFromC
I tried making HttpRequest to Service B and Service C based on the request. But should I do it ? or Should I forward the requests the service B or Service C ? If So I save some TCP connection requests on my side.
What will be difference between making HttpRequest vs forwarding the requests

If you don't want your client to know that you're actually serving the response from B or C, you should forward the request to either B or C.
If you want your client to know that your server will not be handling A directly, but instead will do B or C – so perhaps in the future the client can ask for B or C directly instead of asking for A – then you should send a redirect to the client.
You could instead do what you're suggesting - your server handles incoming request, then makes a separate HTTP request to B or C – but that would just add more complexity to how your server communicates back with the original client. If your server logic somehow "fits" with this approach, I would consider stepping back and re-thinking your server logic to either handle requests directly, or handle it with either a redirect or forward.
Unless your server is unable to handle new inbound requests due to excessive TCP connections, I wouldn't worry about optimizing for that.

Server sends "ping request" to client in a single URL using JAX-RS and RESTeasy

I would like to create a web application that is able to "ping" the client once the client has accessed certain URL (e.g. www.example.com/ping/hello) in order to get the round trip time between server and client. And by "ping" request i mean a simple request with a timestamp from server and client sends back response with its timestamp. I was hoping for this activity to be done with a single URL if possible.
The flow is something like this:
Client goes to the URL
Server sends the response to the client with its timestamp
Client then sends another response to server with new timestamp
Server finally concludes the connection with 200 OK
So far I've only been able to do the first and second steps but not sure how to ensure client to go to the same URL again without back to the first step.
My server code is something like this:
#GET
#Path("/helloping")
public Response getPingServerClient(#Context HttpServletRequest req) {
String result = Long.toString(System.currentTimeMillis());
return Response.status(200).entity(result).build();
//the code to receive the response from client containing timestamp
}
Is there a way to do that?

There are two client to server calls. You'll have to figure out a way to differentiate between these two calls.
I can think of 3 options for this purpose:
HTTP header
Query parameter in GET request
POST request with a marker to differentiate the two calls
The request/response flow will be something like this:
Client -> Server : Request
Server -> Client : Response with timestamp t1
Client -> Server : Request with timestamp t2 and the above mentioned marker
Server -> Client : Response 200
In this approach, you'll have to write custom code at both server and client side to handle the mentioned logic.

I'm not a fan of what you are proposing because you're basically forcing the client to setup up code to effectively become a server, itself. This is inconvenient for the client.
Instead, consider a ping-pong approach where the client first calls the server's ping endpoint, which returns the server's timestamp. As soon as the client obtains the server's ping response, the client is instructed to call a second pong method, which accepts the new timestamp.
It's easier and simpler to require the client to call web service methods than it is to force to client to become a pseudo server. Hence the recommendation.

Java many threads to many threads relation

I have a service that gets requests from many clients and after some processing sends a response to the clients. I use a ThreadPoolExecutor (threadExecuterClient) to handle client requests and put them in a BlockingQueue (requestQueue). Many clients can send concurrent requests. I have another ThreadPoolExecutor (threadExecuterServer) that processes requests in requestQueue. This processing is basically consists of send that request to a server and get response. After processing, I need to send that response to the client which has made that request. I am having difficulties to track which client has made which request. I basically need to find a way to map the client request to the result of processing. The service will be like a gateway.
Any idea to handle this issue is appreciated.
Thanks

I assume your service accepts requests via HTTP ? Accept the request from your service and send back a HTTP 202 response. This response means that the request was accepted for processing. When you send the response, send the Location header to tell the client which URL to invoke to ascertain the status of your request. The client can poll this URL for status and a result.
The URL should contain a unique ID for each request. Your server can track that and populate a response when it is ready.