C#中如何优雅合并签名相同、仅传参不同的GET请求方法？

针对你需要消除重复GET方法、同时保持强类型调用避免字符串错误的需求，推荐以下两种实用方案：

方案一：枚举映射+统一公共方法 #

通过定义枚举限定允许的API端点，内部将枚举值映射到对应的路径字符串，既避免调用者传入错误字符串，又消除了重复的方法定义。

实现步骤： #

1. 定义对应API端点的枚举：

public enum ApiEndpoint
{
    A,
    B,
    C,
    X,
    Y
}

2. 替换原有多个GetX方法为单个公共方法：

public async Task<HttpResponseMessage> GetAsync(ApiEndpoint endpoint)
{
    var pathSegment = endpoint switch
    {
        ApiEndpoint.A => "sys/a",
        ApiEndpoint.B => "sys/b",
        ApiEndpoint.C => "sys/c",
        ApiEndpoint.X => "sys/x",
        ApiEndpoint.Y => "sys/y",
        _ => throw new ArgumentOutOfRangeException(nameof(endpoint), "不支持的API端点")
    };

    return await GetRequest(pathSegment);
}

3. 调用方式：

// 强类型调用，编译期检查，不会传错路径
var response = await yourClient.GetAsync(ApiEndpoint.A);

优点：实现简单，无需额外工具，编译期强类型检查，适合端点数量不多、路径固定的场景。
缺点：新增端点时需要同时修改枚举和switch分支。

方案二：源代码生成器自动生成强类型方法 #

如果希望保留原有GetA/GetB这类直观的方法签名，同时不想手动编写重复代码，可以使用C#源代码生成器自动生成这些方法。

实现步骤： #

1. 定义用于标记生成规则的特性：

[AttributeUsage(AttributeTargets.Class, AllowMultiple = true)]
public class GenerateGetMethodAttribute : Attribute
{
    public string MethodName { get; }
    public string PathSegment { get; }

    public GenerateGetMethodAttribute(string methodName, string pathSegment)
    {
        MethodName = methodName;
        PathSegment = pathSegment;
    }
}

2. 在你的API客户端类上标记需要生成的方法：

[GenerateGetMethod(nameof(GetA), "sys/a")]
[GenerateGetMethod(nameof(GetB), "sys/b")]
[GenerateGetMethod(nameof(GetC), "sys/c")]
[GenerateGetMethod(nameof(GetX), "sys/x")]
[GenerateGetMethod(nameof(GetY), "sys/y")]
public class YourApiClient
{
    private readonly HttpClient _client;
    private readonly UriBuilder _uriBuilder;
    private readonly string _commonApiPath;

    // 构造函数和原有GetRequest方法保持不变...

    // 源代码生成器会自动生成GetA/GetB等方法的实现
}

3. 源代码生成器核心效果：
   生成器会扫描标记了GenerateGetMethodAttribute的类，自动生成对应的异步方法代码，示例生成的代码如下：

public async Task<HttpResponseMessage> GetA()
{
    return await GetRequest("sys/a");
}

优点：完全消除手动重复代码，保留原有强类型方法签名，新增端点仅需添加一个特性标记，适合大量端点的场景。
缺点：需要了解C#源代码生成器的编写，实现复杂度略高。

为什么不推荐Func<>/Action<>？ #

这类委托方案需要提前定义对应路径的委托实例，调用者仍需引用这些实例，既不如枚举调用直观，也无法像强类型方法那样在IDE中获得自动补全提示，反而增加了调用复杂度，因此不适合你的场景。

内容的提问来源于stack exchange，提问作者Josh Panzarella