RestSharp VS CoreWCF

RestSharp

Use RestSharp to create a client library. It requires you to write more code, but it's still a lot less boilerplate than using HttpClient directly.

Let's say we have a simple web app that uses RestSharp, a fairly well-known REST API client library for .NET.

RestSharp:

Are you consuming REST or SOAP web services? For REST APIs you can use https://restsharp.dev/.

Can you not specify the type in the execute call, and see if you can inspect the response? var response = await client.ExecuteAsync(request); I’m on mobile so formatting, but if this is the same client, I just looked at some tests that could suggest this maybe possible https://github.com/restsharp/RestSharp/blob/dev/test/RestSharp.IntegrationTests/RequestBodyTests.cs

A way to read a rest API. If I were in your shoes, I'd probably play with RestSharp: https://restsharp.dev/

On line 16, we append the endpoint that we are going to connect to. In this example, we hit the “/addresses” endpoint. On line 17, we authenticate to Lob using Basic Authentication. Our Lob API key is placed where the username would be and we leave the password empty. Flurl sets the basic-auth headers using the WithBasicAuth method. For those using RestSharp it looks like this.

CoreWCF might be of some use.

You can open a discussion in the CoreWCF repo:

In the later versions you could avoid almost all the XML mess by configuring all of the settings in code. The experience is pretty close to gRPC imo, one plus point is you don't need to learn how to write proto classes. Though you could use protobuf-net for a similar experience. I'm kinda hopeful with CoreWCF, they aim to support more transports (including event gRPC) in the future along with queues other than MSMQ and slowly evolve from being too SOAP specific. There's a lot of potential still for WCF to be a transport agnostic framework that ecompass a lot of transports.

On our end, it's WCF for some servers that haven't been upgraded over. Though it seems we have a path forward for that now with CoreWCF that we're working towards.

There's ongoing work on adding generic queue support. The first two concrete implementations should be MSMQ and RabbitMq from what I recall, though MSMQ will be windows only. But the nice thing about the work is it also opens up other types of message queues for WCF (e.g. Azure Service Bus, RabbitMq, Amazon SQS etc...).

It's seems there's already design work started for a generic queue concept here. I'm pretty interested to see how it goes as well as that'll be a big part for CoreWcf to move forward as a viable choice for greenfield projects and not just a way to migrate existing Wcf projects to Core.

The ongoing .net core port called CoreWcf plans to realize that goal as a future feature on it's roadmap. Where there's plans on adding new transports that didn't exist on .net framework wcf like Grpc, Azure Service bus, Amazon SQS, rabbitmq etc...

If you hit any difficulties or have any problems, feel free to jump on the gitter channel. Details for that are in the repo contributing guide.