Fixes: #559
This change adds disposable support to DaprClient, and updates samples
to dispose it.
I didn't update tests because there are literally hundreds of
non-find-and-replacable cases, and we're not actually doing networking
in our tests so it won't cause an issue.
Fixes: #549
This change mixes up the service invocation APIs to reflect some changes
that are coming down the pipe in dapr/dapr#2683.
We're now using HTTP's semantics and JSON for the main functionality in
`InvokeMethodAsync`. This means that the error handling is simplified
and base on HTTP's status codes rather than trying to abstract over HTTP
and gRPC's different error models. This also means that we're free to
expose HttpRequestMessage and related types in the API because it's no
longer an abstraction.
You can still use `InvokeMethodAsync` to invoke gRPC services, but you
will get a status code in the response, and it will expect JSON, etc,
similar to how gRPC gateway works.
In addition to that we're added `InvokeMethodGrpcAsync` for cases where
you really want *gRPC's* semantics. These methods do Protobuf
serialization, as is a natural choice for gRPC. I do not recommend using
this approach to invoke HTTP services.
---
I also mad updates and improvments to various infrastructure where
necessary (like InvocationException). Also, the gRPC sample in the repo
now uses the new `InvokeMethodGrpcAsync` APIs.
- Adds a new message handler for HttpClient interop
- Adds an easy way to create HttpClient instances
- A bunch of sample cleanup/polish/simplification
The main thing here is the added ability to interop with HttpClient. We'll be making some future changes to the service invocation APIs in DaprClient to address dapr/dapr#2342 since that issues greatly simplifies the interface we're dealing with.
Fixes: #526
Ryan Nowak