时间戳

首页 > 解决方案 > 在相同的状态码中有不同的响应格式是一个好的 RESTFUL API 吗？

rest - 在相同的状态码中有不同的响应格式是一个好的 RESTFUL API 吗？

问题描述

前端是否应该在相同的状态码下处理不同 json 格式的响应？

或者将它们分成不同的状态码是后端的工作？

我问这个是因为我现在提供了一个 restful api，它在状态代码 200 下具有不同的 json 响应。

例如

第一：

{
    "status": "error",
    "msg": "have no user data",
    "inputs": {
        "id": "thisisafaketestid"
    }
}

第二个：

{
    "status": "success",
    "user": {
        "id": 1,
        "name": "somename",
        "email": "someEmail@gmail.com"
    }
}

两个请求的状态码都是 200。

标签： rest

解决方案

状态代码，如200 OK，是通过网络域传输文档的元数据。您向服务器询问资源的当前表示，服务器正在向您发送资源的当前表示。200 OK 完全合适。

想象一下，例如，一个普通的老式 Web 服务器。您请求 的副本/example.json，服务器在磁盘上查找，找到该文件并将其发送回给您。什么是正确的状态码？200 好的。文档内容的语义会改变答案吗？不。

它可能是好的资源设计，也可能不是好的资源设计——也就是说，这种文档模式是否能够带来良好的 API 体验？

在某些情况下，它确实很有意义：描述 job-123 结果的报告可能表明作业失败；描述 server-456 状态的报告可能表明服务器运行状况不佳。

告诉我们我们的域进程不在快乐路径上的文档可能正在共享非常不同的信息，具有不同的字段。

您在此处演示的设计可能“很好”，或者可能是最好的折衷方案。

是的，当这些设计适合时，客户端必须解析文档以确定语义。

推荐阅读