如何处理对成功和失败具有不同响应类型的 WEB API？答案

【问题标题】：How to handle a WEB API that has different responses types for success and failure?如何处理对成功和失败具有不同响应类型的 WEB API？
【发布时间】：2021-09-01 07:48:20
【问题描述】：

我正在开发一个使用 .NET Framework 制作的 WEB API 应用程序。现在，我正在与一家供应商合作，帮助他们将他们的 WEB API 与我们的系统集成。他们的最新更改之一破坏了我的代码。由于我使用的是 RestSharp 库，因此我希望响应始终对应于特定类型的对象，独立于他们一方的成功或失败。

IRestResponse<T> response = await restClient.ExecuteAsync<T>(request);

如果响应成功，他们将发送这样的 json 响应

{message:"", jobNr:"2312312", status:"1"}

然后他们更改了代码，如果任何请求输入错误，他们将发送错误列表，因此响应将是这样的：

[{code:100, message:"contact phone is wrong"},{code:101, message:"the email is not provided"}]

我不喜欢这种方法，因为我认为他们应该对这样的错误做出回应：

{errorMessages:[{code:100, message:"contact phone is wrong"},{code:101, message:"the email is not provided"}]}

但因为它不在我手中。我应该如何处理？只需解析 json 响应并分配给不同类型的对象？谢谢。

【问题讨论】：

首先不要使用 RestSharp 出于这个确切原因，使用 HttpClient 可以更精细地控制读取状态代码和反序列化，您还可以在 DTO 中包含错误/错误数组，序列化程序不会非常关心...但是，狂野的西部并不止于此，我已经看到了 api 资源在相同状态代码上返回许多不同模式的示例（无类型语言有很多要回答的问题，*看着你 javascript*） ...但是，总而言之，不要使用 RestSharp 开始，它已经过了使用日期
响应的状态码是否会因错误而改变？（就像从 200 变成 400）
@A.Mokhtari 是的，他们发送状态码 400。
@TheGeneral 你可能是对的，RestSharp 似乎是一个不错的库，但实际上我敢打赌，有很多更好的库，比如 HttpClient。但是返回不同模式的 API 对我来说似乎是错误的。无论如何，在这种情况下，我设法说服他们将架构应用于我在帖子中遇到的错误。

标签： c# .net asp.net-web-api restsharp webapi

【解决方案1】：

是的，应该手动解析响应。

假设 RestSharp 仍然负责并且原始 API 返回标题为 BadRequest 状态代码的错误，下面的扩展尝试将内容反序列化为错误数组（类型由代码和一条消息，就像问题中提到的那样）。

    public static Error[] AsErrors(this IRestResponse response)
    {
        var empty = new Error[] { };
        try
        {
            return response.StatusCode == System.Net.HttpStatusCode.BadRequest
                    ? JsonSerializer.Deserialize<Error[]>(response.Content)
                    : empty;
        }
        catch (JsonException)
        {
            return empty;
        }
    }

考虑到NormalContent 是您真正期望的响应，用法如下：

    // after creating client and request ...
    var response = client.Execute<NormalContent>(request);
    var errors = response.AsErrors();
    if (errors.Any())
    {
            //Deal with errors
    }
    else
    {
            //response.Data gets populated with RealResult
    }

注意：将过程用作扩展取决于您的案例中响应模式的常见程度。

【讨论】：