StreamObserver used also for unary calls

[kolmodin]

StreamObserver is used for all responses, even when the response is not a stream. To easier understand the generated API it'd be better if unary responses would be treated as such and have a different Observer that suggests that there will only be one response.

[ejona86]

I think this ship has likely sailed. However, I will note that the StreamObserver is a clone of RxJava (which has the Observer interface). Having a separate interface name for the different semantics could be possible, but they would likely have the same methods, so I'm not sure how much it would help in the end.

I agree it is unfortunate, but I think this is a case of design trade-offs.

[kolmodin]

Internally gRPC could still use a StreamObserver for unary, that's fine. But to expose this in the generated API is really unfortunate. And I would think that the API would be different for unary vs streams? The Observable would be for a single value, so there's no need for onComplete().
The StreamObserver javadoc is confusing from the unary perspective;
It is used by both the client stubs and service implementations for sending or receiving stream messages.

[ejona86]

We don't use StreamObserver at all internally. It was on purpose to use the same interface for both; that was considered a benefit to some people. The JavaDoc could likely be improved. If the JavaDoc was improved, could that largely reduce your concern?

At this point any change to the stubs like "use a different interface for unary" would need to be a new stub type; I don't think we are in a good position to make fundamental changes to the existing stubs.

[kolmodin]

I guess I'm too late with these comments.

IMHO, the stub API should state the actual behavior. It should be clear what's expected and what's allowed. Improving the JavaDoc slightly reduces my concern, but since the API is the best documentation it's there the fix really should be applied.

It's easy enough to take an object implementing UnaryObserver and wrap it into an object that implements StreamObserver.
By having the same interface for both unary and streams, we've traded a more accurate and helpful API over a method call to "convert" the interface. I would have preferred the other choice.

But, if improving the JavaDoc is all we can do, then I'd at least like to see that change. :)

Also for each generated method in the stub API, it should be documented that the StreamObserver only takes exactly one value or an error.

[louiscryan]

related to #1474