support invokeXXX method return Response

[naah69]

Describe the proposal

it is not support return Response(with code and headers) in invokeXXX method now. it just convert body data by jackson and return.(there is a bug that jackson can't convert the string without json format)

it is unsupport if somebody need code and header.

i think that it needs deserialize layer and response interface(implement of http and grpc) to adapt.

use the below code to get Response.

invokeMethod(request,TypeRef<Response>)

[skyao]

I have talked with @naah69 about this issue and agreed with him that Dapr java sdk should support this feature because sometime the user need to get more information from HTTP response (for example, http headers).

This will make dapr java sdk more flexibility.

I will review the PR code.

[naah69]

I have talked with @naah69 about this issue and agreed with him that Dapr java sdk should support this feature because sometime the user need to get more information from HTTP response (for example, http headers).

This will make dapr java sdk more flexibility.

I will review the PR code.

Is there any progress?

[artursouza]

We should create a new API that is HTTP specific instead of having a break change here. This API was originally designed to be protocol agnostic.

[yaron2]

We should create a new API that is HTTP specific instead of having a break change here. This API was originally designed to be protocol agnostic.

Using an HTTP client directly (which is the preferred method for service invocation) is essentially HTTP specific and will address the problem described here.

[yaron2]

Discussion here: https://github.com/dapr/dotnet-sdk/issues/526.

cc @rynowak

[artursouza]

We should create a new API that is HTTP specific instead of having a break change here. This API was originally designed to be protocol agnostic.

Using an HTTP client directly (which is the preferred method for service invocation) is essentially HTTP specific and will address the problem described here.

In Java SDK, we handle serialization on behalf of the user too (differently from .Net SDK). So there is an advantage of letting the SDK handle the abstraction for the user.

[yaron2]

We should create a new API that is HTTP specific instead of having a break change here. This API was originally designed to be protocol agnostic.

Using an HTTP client directly (which is the preferred method for service invocation) is essentially HTTP specific and will address the problem described here.

In Java SDK, we handle serialization on behalf of the user too (differently from .Net SDK). So there is an advantage of letting the SDK handle the abstraction for the user.

Agreed