时间戳

首页 > 解决方案 > 为同一请求返回不同的 JSON 结果 - 这是否违反了 REST？

json - 为同一请求返回不同的 JSON 结果 - 这是否违反了 REST？

问题描述

请注意 Roy Fielding 关于 REST 设计、指南和原则的以下内容。

5.2.1.1 资源和资源标识符

REST 中信息的关键抽象是资源。任何可以命名的信息都可以是资源：文档或图像、时间服务（例如“洛杉矶今天的天气”）、其他资源的集合、非虚拟对象（例如人）等等. 换句话说，任何可能成为作者超文本参考目标的概念都必须符合资源的定义。

资源是到一组实体的概念映射，而不是 在任何特定时间点对应于映射的实体 。

更准确地说，资源 R 是一个随时间变化的隶属函数 MR(t)，它在时间 t 映射到一组等效的实体或值。集合中的值可以是资源表示和/或资源标识符。资源可以映射到空集，这允许在该概念的任何实现存在之前对该概念进行引用——在 Web [61] 之前，这个概念对于大多数超文本系统来说都是陌生的。有些资源是静态的，因为在创建后的任何时间检查它们时，它们总是对应于相同的值集。随着时间的推移，其他人的价值差异很大。

唯一需要对资源保持静态的是映射的语义，因为语义是一种资源与另一种资源的区别。

关键点已加粗，我所包含的其余段落是为了上下文。

这是场景。

我有一个有端点的 web api：http ://www.myfakeapi.com/people

当客户端向此端点发出 GET 请求时，他们会收到一个人员列表。

Person
{
  "Name": "John Doe",
  "Age": "23",
  "Favorite Color": "Green"
}

好的，那很酷。

但是，如果我有一个没有最喜欢的颜色的“人”并且我想像这样返回它们，这是否违反了 REST 设计实践和原则：

Person
{
  "Name": "Bob Doe",
  "Age": "23",
}

或者我应该像这样返回它们：

Person
{
  "Name": "Bob Doe",
  "Age": "23",
  "Favorite Color": null
}

问题是请求资源的客户端必须做额外的工作才能首先查看该属性是否存在。有些“人”有最喜欢的颜色，有些则没有。如果 'Favorite Color' 的 json 属性不存在，是否违反 REST 原则？或者是否应该为该属性赋予“null”或空白值？

REST 对此有何看法？我在想我应该返回一个 null 而不是通过省略属性来更改客户端请求的资源的表示。

标签： jsonrest

解决方案

在我的脑海中，我想不出这违反了任何 REST 约束（如果你有兴趣，这里是一个简短概述的链接）。它也不违反 GET 请求的幂等性。但是，这仍然是不好的做法。

API 的使用者应该知道会发生什么，理想情况下这应该有很好的文档记录（我非常喜欢为此使用Swagger）。任何预期的变化都应该传达给消费者，可能以发行说明的形式。可能对您的消费者造成破坏的更改应在您的 API 的新版本中交付。

由于您的 Person1 和 Person2 在技术上是不同的对象结构，因此可能会自行中断（让我们面对现实，我们并不总是发现边缘情况作为开发人员）。您不只是希望您的 API 在基本层面上工作并让最终用户见鬼去向——您希望在设计它时考虑到最终消费者，以便他们的生活变得更轻松。

推荐阅读