Proposal: Deprecate HTTP client in SDK

[johnewart]

Describe the proposal

Given that the existing HTTP implementation is causing some issues with long-term maintenance and requires additional (potentially conflicting) dependencies for developers using the Java SDK, we should deprecate the HTTP transport that the client provides. I suspect that SDK consumers are largely using gRPC (maybe even entirely, though this is purely a guess and having some data would be nice) and we can use this as an opportunity to slim down the SDK.

In the interim I also propose the we also consider moving the HTTP client code into its own package that would need to be depended on separately to isolate the dependencies so that only those projects requiring HTTP support will have to take them along with the SDK (it would also, I think) make some compatibility issues with the core SDK go away if I understand correctly.
(If we decide to do this I can open a separate issue for this and link it to a PR)

[skyao]

In the interim I also propose the we also consider moving the HTTP client code into its own package that would need to be depended on separately to isolate the dependencies so that only those projects requiring HTTP support will have to take them along with the SDK (it would also, I think) make some compatibility issues with the core SDK go away if I understand correctly.

hi, @johnewart I have similar proposal as you said here: #785 . And Zhikun had done some work for this splitting as I described in my proposal.

BTW: I totally agree with that we should remove http api in java sdk.

[ParrySMS]

A good proposal. But I suspect that some SDK consumers, enterprise in particular, may not be able to use gRCP for some reasons. So the HTTP and gRPC are both important.

[mthmulders]

In #626, @artursouza proposed moving to Java 11 as the baseline. This would allow using the HTTP client introduced with Java 11. Without extra dependencies, so without conflicts with other possible dependencies, but for those who need it, still fully operational HTTP support.

[johnewart]

My question (and I can put this in #626) is this -- are we going to effectively write-off Java 8 users? According to New Relic's numbers from earlier this year, something like just short of 50% of apps using their Java SDK are still using Java 8 (https://newrelic.com/resources/report/2022-state-of-java-ecosystem#toc-java-11-is-the-new-standard) but that's not entirely related to this thread.

If we split it into separate artifacts then it's possible to support both 11+ and 8 but we would have to make sure that we use only Java 8 supported APIs and, even with the split, Java 8 consumers would have to use gRPC to get updates. At which point, if all Java 8 consumers are using gRPC, why would we support HTTP? It seems to me that those customers using Java 8 in production would be the most likely to have limitations on protocols, but this is just a guess.

[mthmulders]

Do we have any data on the protocol use of Java/Dapr users? How many of them use HTTP, vs. how many of them use gRPC? I don't think we should deprecate HTTP support only because we struggle to get the dependencies right.

How about this: we move both protocols out of the main dapr-sdk artifact.

• Those that want to use HTTP and are pre-Java 11 could use dapr-sdk-java8 (the current implementation with OkHttp).
• Those that want to use HTTP and are on Java 11 or above could use dapr-sdk-java11 (implemented with the native HTTP client).
• Those that want to use gRPC could use dapr-sdk-grpc (the current implementation with gRPC).

Granted, it's a bit more maintenance work. But on the other hand, it would make the SDK more lightweight, as consumers only pull in what they really need.

[johnewart]

As much as I would love it, I suspect there is not much beyond anecdotal data points. From my perspective this proposal is actually somewhat independent of the Java SDK in that the underlying question is "why do we (Dapr) support HTTP as a transport protocol in the SDKs?" but it just happens to solve two problems at once in this case.

Deprecating HTTP in this case (from my perspective) just also happens to have the additional benefit of making the dependency issue more manageable for Java in that we would only have one package to maintain (dapr-sdk) and no external HTTP library dependencies (i.e OkHttp) for any version of Java.

This is quite possibly a conversation for a broader audience but my question is this: is there truly a substantial set of users who would take a dependency on an SDK (Java, or otherwise) but expressly not want to (or be unable to) use gRPC? I can't think of any scenarios where this might be the case off the top of my head, but it's quite possible that there are enough people for whom this would actually be the case and it's worthwhile supporting HTTP and gRPC. However, if the answer to that question is "no" then we should ask ourselves what benefit there is to continuing to carry it around with us (in any SDK for that matter).

Clearly there are values in the sidecar being able to speak both gRPC and HTTP, particularly for the case where clients might be resource-constrained and need to be able to just make HTTP calls to Dapr using libcurl or another simple mechanism. However, in the case where a developer is taking an SDK as a dependency that does not seem like using gRPC would be a blocker.

Thoughts?

[skyao]

Do we have any data on the protocol use of Java/Dapr users? How many of them use HTTP, vs. how many of them use gRPC? I don't think we should deprecate HTTP support only because we struggle to get the dependencies right.

How about this: we move both protocols out of the main dapr-sdk artifact.

• Those that want to use HTTP and are pre-Java 11 could use dapr-sdk-java8 (the current implementation with OkHttp).
• Those that want to use HTTP and are on Java 11 or above could use dapr-sdk-java11 (implemented with the native HTTP client).
• Those that want to use gRPC could use dapr-sdk-grpc (the current implementation with gRPC).

Granted, it's a bit more maintenance work. But on the other hand, it would make the SDK more lightweight, as consumers only pull in what they really need.

This is what I'm trring to do in proposal #785

But this will introduce another problem: complexity!

The simplest way is to remove dapr http api and use grpc only.

[skyao]

Deprecating HTTP in this case (from my perspective) just also happens to have the additional benefit of making the dependency issue more manageable for Java in that we would only have one package to maintain (dapr-sdk) and no external HTTP library dependencies (i.e OkHttp) for any version of Java.

Agree!

I would like to close my proposal #785 which is trying to better control the http and grpc dependencies and split the dapr java sdk project to many small projects.

We should resolve the problem by make things simple.

[mthmulders]

I am not in favor of removing HTTP support. Dapr advertises the HTTP API quite prominently in the Getting Started Guide. As a result, I think it is something Dapr users expect to work when using the official Dapr SDK for Java.

I feel that by removing HTTP support purely because we struggle to get the dependencies right, we're moving "our" problem to the end user.

[artursouza]

I am not in favor of removing HTTP support. Dapr advertises the HTTP API quite prominently in the Getting Started Guide. As a result, I think it is something Dapr users expect to work when using the official Dapr SDK for Java.

I feel that by removing HTTP support purely because we struggle to get the dependencies right, we're moving "our" problem to the end user.

As of now, the Java SDK is the only one that supports both protocols. There is no advantage to offer both and HTTP protocol is significantly slower than gRPC. If the community has feedback of scenarios where using the HTTP protocol under the Java SDK is required, we can stop the deprecation. BTW, we still plan to support service invocation over HTTP and the callback APIs in springboot, this is about deprecating the other APIs into the sidecar.