如何从RESTful API处理面向对象编程中的复杂信息可用性

Question

我的问题是，我正在处理一个返回对象信息的RESTful API，在编写表示它们的类时，我不确定如何最好地处理每个变量可用性的所有可能性。据我所知，有5种可能性：信息

• 可用
• 未被请求
• 正在请求（异步）
• 不可用
• 不适用

因此，使用值或null来表示对象的数据是不够的。举个更具体的例子，我正在使用关于美国国会的API，问题如下：

我请求关于法案的信息，其中包含有关发起立法者的存根。最终，我需要请求有关该立法者的所有信息。并非所有立法者都拥有所有信息。众议院的成员不会有参议院班级（参议员的六年任期错开，每两年有三分之一过期，众议院每两年完全重新选举）。有些人没有Twitter ID，只是因为他们没有。当然，如果我已经请求了信息，就不应再次尝试请求。

我看到了几个选项：

• 我可以创建一个Legislator对象，并填充它所拥有的信息，但是我必须有一些跟踪getter和setter信息可用性的机制。这就是我现在正在做的，但它需要大量重复的代码。
• 我可以为缩写对象创建一个单独的类，并在获得更多信息时使用不可变的“完整”对象替换它们，但是然后我必须非常小心地替换所有对它们的引用，并且还要经历许多困难，尤其是不可用和不适用的信息。

因此，我想知道其他人对这个问题的看法。有没有其他（更好的？）处理这种复杂性的方法？不同方法的优点和缺点是什么？在选择方法时应考虑哪些因素？

[注意：我正在使用Objective-C工作，但这并不一定特定于该语言。]

- Stephen Searles

Answer 1

如果你想在客户端上将那些远程资源视为对象，那么请大力忘记REST这个词。您会把自己逼疯的。请接受您正在执行HTTP RPC，并像执行任何其他RPC项目一样继续。

但是，如果您真的想要使用REST，则需要了解REST缩写中“状态传输”部分的含义，并阅读有关HATEOAS的文章。对于构建客户端来说，这是一个巨大的思维转变，但它确实具有许多好处。但也许您不需要那些特定的好处。

我知道的是，如果您尝试使用“REST API”从网络检索对象，您会得出REST是一堆垃圾的结论。

- Darrel Miller

---

非常同意。那个链接的问题（以及您对它的（被接受的）回答）都非常出色；尤其是您的回答非常棒。我可能会从中摘录一些内容，向我的管理层证明一些决策。 - Paul Sonier

Answer 2

这是一个有趣的问题，但我认为你可能有点过于深入思考了。

首先，我认为你对信息可能的状态考虑得有些过多；请考虑更基本的情况，即你要么拥有信息，要么没有。为什么你拥有信息并不重要，除了一种情况。让我解释一下；如果某个法案、立法者或任何事物的信息不适用，你就不应该请求它/需要它。那种“状态”是无关紧要的。同样，如果信息正在被请求，那么它只是还没有可用；你真正关心的唯一状态是你是否拥有信息或者你还没有信息。

如果你开始担心请求过程的更深层次，你就会冒着陷入管理状态的深度无限循环的风险；在我得到信息和现在之间，信息是否发生了变化？你所知道的关于信息的一切就是你被告知它是什么。这是REST过程的基础；你正在获取底层数据的表示，但毫无疑问；表示不是底层数据，就像国会议员的名字不是国会议员本人一样。

其次，不必担心信息的可用性。如果一个对象有一个子对象，在查询对象时，请查询子对象。如果返回数据，则很好。如果返回数据不可用，那也是子对象数据的表示；它只是与您所希望的不同的表示，但同样有效。我会将其表示为具有空值的对象；该对象存在（因为它属于父级而被实例化），但您没有关于它的有效数据（由于某种原因，返回的表示为空；缺少可用性，服务器停机，数据更改等）。

最后，真正的关键在于您需要记住RESTful结构是由超媒体驱动的；对不返回完整对象数据的对象的请求应返回用于请求子对象数据的URI；等等。关键在于这些结构不是静态的，就像您的对象结构似乎希望将它们处理一样；它们是动态的，由服务器确定表示（即相互关系）。试图提前以具体对象表示来定义它意味着您正在以REST从未意味着要处理的方式处理系统。

- Paul Sonier