Circular Dependency with two depending Services

Although your object graph is cyclic (AccountService -> HttpService -> AccountService) your call graph is not. The call likely is something as follows:

AccountService.Login
    -> HttpService.Post
        -> HttpService.AddAuthentication
            -> AccountService.Identity

Cyclic object graphs with non-cyclic call graphs often happen on components that violate the Single Responsibly Principle. The more functionality (methods) classes get, the bigger the chance their object graphs become cyclic. Splitting classes up in smaller, more focused pieces, not only fixes the cyclic-dependency problem, but often also improves the design of the application.

I think your case is actually quite similar to the example that I discuss in section 6.3 of DIPP&P. That section specifically talks about fixing cyclic dependencies.

Long story short, I think your best bet is to split AccountService in (at least) two services:

• One service responsible of logging in and logging out
• A second service responsible of getting the user's identity.

Both services get their own interface and those new interfaces are now less wide compared to IAccountService. This improves your chances of adhering to the Interface Segregation Principle.

Here's an example of how that looks like:

Let's start with the new interface definitions:

// Contains Login and Logout methods of old IAccountService
public interface IAuthenticationService
{
    Task Login(Credentials Credentials);
    Task Logout();
}

// Contains Identity property of old IAccountService
public interface IIdentityProvider
{
    // For simplicity I added a setter to the interface, because that keeps
    // the example simple, but it is possible to keep Identity read-only if
    // required.
    Identity Identity { get; set; }
}

// This interface is kept unchanged.
public interface IHttpService
{
    Task<T> Get<T>(string uri);
    Task Post(string uri, object value);
    Task<T> Post<T>(string uri, object value);
}

Let's look at the implementations next, starting with the IAuthenticationService implementation:

// Old AccountService, now depending on IIdentityProvider
public class AuthenticationService : IAuthenticationService
{
    private readonly IHttpService _httpService;
    private readonly ILogService _logService;
    private readonly IIdentityProvider _identityProvider;
    
    public AccountService(
        IHttpService HttpService,
        ILogService LogService,
        IIdentityProvider IdentityProvider)
    {
        _httpService = HttpService;
        _logService = LogService;
        _identityProvider = IdentityProvider;
    }

    public async Task Login(Credentials Credentials)
    {
        _identityProvider.Identity = await _httpService.Post<Identity>(
            "api/rest/v1/user/authenticate", Credentials);
    }
}

This "new" AuthenticationService contains part of the code of the AccountService and the rest of the old AccountService logic is hidden behind the new IIdentityProvider abstraction, which is injected into AuthenticationService. This refactoring is very similar to the Facade Service refactoring (for an elaborate discussion on the Facade Service refactoring, see section 6.1 of DIPP&P).

IdentityProvider implements the new IIdentityProvider interface and contains the old logic from AccountService:

public class IdentityProvider : IIdentityProvider
{
    public Identity Identity { get; set; }
}

And finally, HttpService that now depends on IIdentityProvider instead of IAccountService:

// Now depends on IIdentityProvider instead of IAccountService
public class HttpService : IHttpService
{
    private readonly HttpClient _httpClient;
    private readonly IIdentityProvider _identityProvider;
    private readonly ILogService _logService; 

    public HttpService(
        HttpClient HttpClient,
        IIdentityProvider IdentityProvider,
        ILogService ILogService)
    {
        _httpClient = HttpClient;
        _identityProvider = IdentityProvider;
        _logService = LogService;
    }

    private async Task AddAuthentication(HttpRequestMessage Request)
    {
        // Now uses the new IIdentityProvider dependency instead
        // of the old IAccountService, which caused the cycle.
        Request.Headers.Authorization = new AuthenticationHeaderValue(
            "bearer", _identityProvider.Identity.SystemToken);
    }
}

Using this new design, the object graph is no longer cyclic and can be constructed as follows:

var identity = new IdentityProvider();
var logger = new LogService();

new AccountService(
    new HttpService(
        new HttpClient(...),
        identity,
        logger),
    logger,
    identity);