Sendgrid-csharp: Return HttpResponseMessage instead of SendGrid.Response

[thomaslevesque]

Issue Summary

APIs like SendGridClient.SendEmailAsync return a custom SendGrid.Response object, which is built entirely from a HttpResponseMessage. The problem is that this custom Response class brings absolutely no value; there's nothing in it that wasn't already in HttpResponseMessage, and it actually loses information (e.g. ReasonPhrase) and access to helper methods like EnsureSuccessStatusCode...

I suggest to remove SendGrid.Response from the next major version, and return HttpResponseMessage instead.

(Or even better: throw an appropriately typed exception directly from SendEmailAsync when a non-success response is received, so that the users don't have to parse the error response themselves. I was actually very surprised to discover that SendEmailAsync didn't throw when the SendGrid API returned an error; it's too easy to forget to check the response and just assume everything worked since no exception was thrown. But this should probably be a separate issue.)

Steps to Reproduce

N/A (it's not a bug, it's an API design issue)

Technical details:

• sendgrid-csharp Version: 9.10
• Platform: ASP.NET Core
• .NET Version: .NET Core 2.1

[Jericho]

If you are looking for a library that properly parses responses returned from the SendGrid API and throws exceptions whenever a non-success response is received, I suggest you look at StrongGrid. (disclaimer: I'm the author)

[thomaslevesque]

If you are looking for a library that properly parses responses returned from the SendGrid API and throws exceptions whenever a non-success response is received, I suggest you look at StrongGrid. (disclaimer: I'm the author)

Thanks @Jericho! I was considering writing such a library myself if I couldn't find one :wink:
Looking at the code of the official lib, I realize it's just a (very) thin wrapper around HttpClient, which isn't very useful.

[thinkingserious]

Hi @thomaslevesque,

Thanks for taking the time to write up this issue!

This version of the library was indeed designed to be a thin wrapper around our v3 API to demonstrate usage of our new 230+ endpoints as opposed to the single endpoint this library replaced. The first step after that was to implement the most common use cases.

We would love to pull in the awesome functionality that StrongGrid has already achieved (@Jericho's work is outstanding), with an upgrade to the Response class being one of them. I believe that the Response class should supply meaningful responses based on this documentation along with troubleshooting guidance or well formed data to log. In addition, I think it's a great idea to return HttpResponseMessage as part of the payload.

I've added this to our Hacktoberfest celebration :)

With Best Regards,

Elmer

[Jericho]

@thomaslevesque completely agree. This official library is very thin. StrongGrid on the other hand is what .Net developers expect: error handling, strongly typed, automatically works around some know bugs in the API, etc. StongGrid also covers every single endpoint in the API (there are in excess of 200) while official library primarily covers the mail.send endpoint and only a handful other endpoints but far far far from the 200+ that the API provides. Finally, StrongGrid provides a parser for webhook events and a much more advanced "IP address warmup engine" than the one provided by SendGrid.

[thinkingserious]

BTW, I have not gotten to it, but before we hit the mid-point of Hacktoberfest, I plan to have issues developed in this repo to gain the coverage that StrongGrid has, based on the conversation here.

[Fabio-Alexander-Bueno]

@thomaslevesque see if this PR #796 resolve your problem. If it didn't solve what could be improved?

[thinkingserious]

Hello @thomaslevesque, @Fabio-Alexander-Bueno,

I'm closing this one, since I think that https://github.com/sendgrid/sendgrid-csharp/pull/1019 will resolve this issue.

If you have further feedback, please free to comment here and re-open or on #1019. Thanks!