defmodule Http do
  def get(client, url, opts \\ []) do
    client.get(url, opts)
  end
end

defmodule Http.Client do
  @callback get(URI.t | String.t, keyword) :: term
end

defmodule Http.Httpoison do
  @behaviour Http.Client
  def get(url, opts) do
    HTTPoison.get(url, opts)
  end
end

You’d never actually call functions on Http.Httpoison directly, but only though Http.

Afaik what you’re looking for is not possible at the moment. Packages like ecto only put the full parameter version of their functions on behaviours, while the concrete implementations do implement optional params. In a recent experiment with mocking Ecto.Repo using Mox I found this to be unsatisfying, as one needs to not skip optional parameters in lots of places to not get in trouble with Mox. On the other hand the behaviour (/interface) clearly states that those functions need to have certain arguments, and one shouldn’t depend on the concrete implementation, but only the interface, when intending to switch out multiple implementations.

Correct. I’m not so sure about the complexity though. Yes, it’s “slightly more” code and especially a module more. Yes, you need to deal with passing the implementation as e.g. a parameter. But you’ll get lesser complexity for any of your implementations, as they don’t need to deal with any optionality/function heads and can just provide an implementation for a clean and simple behaviour. The part dealing with your optional params becomes part of your functional core and is therefore easier to test.

Basically – for the amount of code you need to have – this approach moves the line between your core and the ugly outside world further out / makes the edge smaller.