One-Off: new release

[zmontgo]

Just wanted to propose you make a new release, v0.2.2, to include the new headers in the crates.io release until the API 3.1 update can be released.

[zmontgo]

Edit: I just read your last comment before you closed the pull request. Thank you much.

[LeoBorai]

Hi @zmontgo! Thanks for kickstarting this discussion!
As we have been discussing on #5, the Mailjet Send API 3.1 support is planned but is not yet started.

Our current architecture is intended for splitting the support for Send API V3 and Send API V3.1, and at first I thought it would be nice to have both implementations, but as of today I don't see any benefits on doing such approach.

I believe that we could actually drop support for Send API V3 and move into supporting versions from Send API V3.1 onwards.

What do you think about doing this for a next release?

[LeoBorai]

Hey @zmontgo hows going?

I have been checking other API Clients written in Rust looking for patterns/architecture, and I found very intuitive and simple to understand, the Cloudflare's API Client for Rust on cloudflare/cloudflare-rs.

Let me know your thoughts!

[zmontgo]

@EstebanBorai sorry for ghosting you, tumultuous time in my life. If you're still looking to work on this, let's do it! Otherwise, consider adding me as a maintainer and I'll start spearheading development. Up to you!

[LeoBorai]

Hi! No worries! Of course we can still work on this together!

[zmontgo]

Ideally we should offer a comprehensive, wrapper that encapsulates the entire API surface with feature flags/modular design. I can write clear docs along the way.

[LeoBorai]

Yeah! Feel free to open issues as you go, so we discuss each layer together!

[zmontgo]

I really love the way the Cloudflare API client looks. My proposal is, if we are already wanting to implement breaking changes, let's opt to support all versions of the API and rebuild it from the ground up to make some quality of life improvements. I still have some things to go through, but a few of the changes I want to make:

• Never panic
• Use a builder design pattern rather than mutable references
• Define the possible API responses and their structure using enums and structs, automatically parsing using serde [things like #[serde(untagged)] are especially helpful]
• Use the reqwests library
• Restructure and rename the file structure, as well as file/method names

Some of these were inspired by the cloudflare-rs package. I really love this...

#![forbid(unsafe_code)]

pub mod endpoints;
pub mod framework;

One other thing, just worth mentioning, is that I was seized with the idea of letting this compile into wasm, but I am not sure there would be enough consumers [due to the fact that you would have to send private API keys and let the client decide when to send emails] to make that officially supported. Maybe I'm not thinking of something, so if you can we should consider that when architecting this.

If I remember correctly, this was the direction you were wanting to go, and I'll be happy to co-author this with you. I think a method of communication more conducive to frequent back-and-forth may be useful if this is what we end up doing, so feel free to email me at [email protected] and I can give you my Discord username or whatever else you'd like.

[LeoBorai]

Sounds good to me! Very good insights and ideas @zmontgo!
I agree with your take on this, feel free to begin working on it!