thinkingserious
commented
8 years ago Hello @keleshev,
Thanks for the question!
We have recently re-written all of our libraries (currently they are in beta for a few more weeks and the code is in the v3beta branches of each of our respective libraries) to support all of our v3 web api endpoints, including the new /mail/send.
During this process, we decided to not rely on third parties for our HTTP clients (and in the future, we would like to allow you to pass in whatever HTTP client you like). So we rewrote the HTTP clients so that they have no third party dependencies (except Java, because their native HTTP client does not support PATCH). When we did that, we realized that people could use those HTTP clients as stand alone code for simple access to RESTful APIs. So we split those HTTP clients out into their own repos and made them generic.
We also split out the SMTP libraries because there are some people who only need that functionality to interact with SendGrid. Now, with the new /mail/send endpoint, the functionality of the SMTPAPI header is included.
With Best Regards,
Elmer
Sorry, if this is a wrong place to ask this particular question.
I noticed that SendGrid created a few HTTP and SMTP in different languages, Python, Ruby, Go, etc. So I was wondering, what is the grand idea behind this?
I know that at least in Python there are quite a few good libraries for HTTP (like requests) and SMTP. So I'm interested to know why you're writing these libraries? I'm curious because I have some suspicion that you would like to create HTTP and SMTP libraries with same API across different languages, because you want to generate SendGrid clients automatically from some declarative description. Is something like this the case? Or are you, maybe, doing this to have more control over dependencies?