Nested Interfaces and Mega Classes

[chrstophr-wltrs]

Hi everyone 👋 I'm working on some integration tests for a handful of very large ASP.NET applications. In the source code, these endpoints are split up into "controllers", and I'm trying to have my test code somewhat mirror that. It also makes sense to have related methods in different files from a logical perspective. Let's say I have an "Admin" API and an "External" API. For the Admin API, I might have some interfaces in different files like this:

/* INotification.cs */
namespace Application.Admin;

public interface INotification
{
	[Get("/notification")]
	Task<IApiResponse<List<Notification>>> View();

	[Put("/notification/clear")]
	Task<IApiResponse> Clear();
}

/* IUser.cs */
namespace Application.Admin;

public interface IUser
{
	[Get("/user")]
	Task<IApiResponse<List<UserDetails>>> ViewAll();

	[Post("/user")]
	Task<IApiResponse<UserDetails>> Add([Body] UserDetails request);
}

And the External API would look like this:

/* INotification.cs */
namespace Application.External;

public interface INotification
{
	[Get("/notification/unread")]
	Task<IApiResponse<List<Notification>>> View();

	[Get("/notification/history")]
	Task<IApiResponse<List<Notification>>> ViewHistory();

	[Put("/notification/clear")]
	Task<IApiResponse> Clear();
}

/* IUser.cs */
namespace Application.External;

public interface IUser
{
	[Get("/user")]
	Task<IApiResponse<List<UserDetails>>> ViewAll();

	[Get("/user/{userId}")]
	Task<IApiResponse<UserDetails>> View(Guid userId);
}

Of course, when you have three or more interfaces with the same name in one project, Refit refuses to auto-generate implementations of those interfaces, even if they're in different namespaces.

One possible solution is to instead generate a single interface using partials:

/* Notification.cs */
namespace Application.External;

public partial interface IExternal
{
	[Get("/notification/unread")]
	Task<IApiResponse<List<Notification>>> ViewNotifications();

	[Get("/notification/history")]
	Task<IApiResponse<List<Notification>>> ViewNotificationHistory();

	[Put("/notification/clear")]
	Task<IApiResponse> ClearNotifications();
}

/* User.cs */
namespace Application.External;

public partial interface IExternal
{
	[Get("/user")]
	Task<IApiResponse<List<UserDetails>>> ViewAllUsers();

	[Get("/user/{userId}")]
	Task<IApiResponse<UserDetails>> ViewUser(Guid userId);
}

This means that every method must have a unique name across the entire API, which does end up feeling pretty redundant and silly.

I was wondering, does anyone know if there's some way to structure your interfaces such that you could consume it like this?

var adminApi = RestService.For<IAdmin>(baseUrl);
var notifications = await adminApi.INotification.View();
var users = await adminApi.IUser.ViewAll();

That's probably too specific for an auto-generator, but it seemed like it wouldn't hurt to ask.

[glennawatson]

Refit does not support property-style nested interface composition like adminApi.INotification.View(). Each Refit interface maps to one flat client, and the generator keys generated implementations by simple type name, which is why three same-named interfaces in different namespaces collide.

Practical patterns that work today:

• One interface per logical controller, each resolved as its own client. Keep them distinct types (e.g. IAdminNotificationApi, IExternalNotificationApi) and register each:

services.AddRefitClient<IAdminNotificationApi>().ConfigureHttpClient(...);
services.AddRefitClient<IExternalNotificationApi>().ConfigureHttpClient(...);

Then group them yourself in a façade if you want adminApi.Notifications.View():

public class AdminApi(IAdminNotificationApi notifications, IAdminUserApi users)
{
    public IAdminNotificationApi Notifications { get; } = notifications;
    public IAdminUserApi Users { get; } = users;
}

This gives the call-site ergonomics you described without unique method names across the whole API, and keeps files split per controller.

• The partial-interface approach you found works but forces globally unique method names, which is the redundancy you noticed.

The name-collision on same-named interfaces in different namespaces is a real limitation of the generator (it disambiguates by simple name). A thin façade is the cleanest workaround for now.