I dont want to tell others how to write code, but if you need to provide a rest api mock to test more than just the thing that does requests, your code could likely be improved a lot by decoupling things.

Let's say you are making a feature which will call into an external API, send an email based on the response and then also write something to the DB.

How do you ensure this actually works and for example emailing isn't broken accidentaly by a future refactor?

Of course that you can and should test each individual component in this scenario, but at some point you need to mock more than "the thing that does requests" and check if it click with other components.

I would argue that when you are at the point of testing that the actual api works as you expect what you need is an integration test not a unit test. And you shouldn't mock it because if you mock it you won't actually be testing what you wanted to test. For unit tests use a Fake for anything that interacts with an external system.

How is my code going to be improved by it outside of writing tests?

Not the solution you're looking for but I personally like having a wrapper and doing something like this (let's pretend this is for Twilio)

    trait TwilioClient {
        send_sms(num: &str, text: &str)
    }

    struct TwilioClientHttp {
        client: HttpClient
    }

    impl TwilioClient for TwilioClientHttp {...}

    struct TwilioClientFake {}

    impl TwilioClient for TwilioClientFake {...}

And that's nice because now we have that abstraction layer away from IO. This will feel like overkill in some cases for sure, but I do find it great for a lot of cases. You can even just make that TwilioClientFake inside of the testing area itself directly. Go has done a good job pushing the idea of accepting interfaces everywhere, but it's ad hoc construction of those is a bit leaner.

Sorry for the StackOverflow-esque non-answer though. Also excuse my Rust, it's a bit rusty.

I use the mockall crate myself, which works rather well. It does however mean that you need to generally write your code as traits, and pass them around as traits.

https://github.com/asomers/mockall

Your specific task sounds like maybe it calls for Wiremock, since it is presumably a third party HTTP API and you'd like to pretend this service has some defined behaviour while testing your integration does what you expect.

I found wiremock to be excellent. What I really struggled with was mocking out other bits of rust code or setting up the DB with the right data and wiping it after the test. All this stuff that just comes for free in other language/test setups you have to manually reimplement.

What about httpmock or wiremock?