如何通过RESTful API处理OOP中信息的复杂可用性

Question

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

• 可
• 没有要求
• 目前正在请求（异步）
• 不可用
• 是不适用

因此，有了这些对象用数值表示它的数据或null不会削减它。举一个更具体的例子，我正在使用一个关于美国国会的API，所以问题如下：

我要求关于帐单的信息，它包含关于赞助立法者的存根。 我最终需要请求关于该立法者的所有信息。并非所有的立法者都会获得所有的信息。众议院的*不会有参议院*（参*的六年任期交错，因此每两年届满一次，众议院每两年完全连任）。有些人不会有推特ID，只是因为他们没有。当然，如果我已经要求提供信息，我不应该再次请求它。

有一对夫妇选择我看到：

• 我可以创建一个立法者对象，并与我有什么样的信息填写，但后来我不得不和getter和setter跟踪信息可用性的一些机制。这就是我现在正在做的事情，但它需要很多的重复代码。

• 我能为缩写对象来创建一个单独的类和替换他们当我得到更多的不可变“完整”的对象，但我必须非常小心更换他们所有引用，也经历了一堆不可用的环，特别是不适用的信息。

所以，我只是想知道其他人在这个问题上采取了什么。还有其他（更好的）方法来处理这种复杂性吗？不同方法的优点和缺点是什么？在选择方法时我应该考虑什么？

[注：我在Objective-C的工作，但这并不一定是特定于语言]

Answer 1

如果你要正确对待这些远程资源的客户端对象，在做自己一个巨大的忙，忘了REST的流行词。你会让自己疯狂。只要接受你正在做HTTP RPC并继续进行，就像你做任何其他RPC项目一样。

但是，如果您确实想要执行REST，您需要了解REST缩写词的“状态转移”部分的含义，您需要阅读有关HATEOAS的内容。这对建立客户来说是一个巨大的心理转变，但它确实有一些好处。但是，也许你不需要那些特殊的好处。

我所知道的是，如果您尝试使用“REST API”通过电线检索对象，则会得出REST为load of crap的结论。

Answer 2

这是一个有趣的问题，但我认为你可能会稍微偏执一点。

首先，我认为你正在考虑可能的信息状态太多;考虑一下你要么拥有这些信息，要么就是不这样做。为什么你有这些信息并不重要，除了在一个案例中。让我解释;如果关于特定账单或立法者的信息或任何内容不适用，您不应该要求/需要它。这个“国家”是无关紧要的。同样，如果信息正在被请求的过程中，那么它就根本不可用;你真正关心的唯一状态是你是否拥有这些信息，或者你是否还没有这些信息。

如果您开始担心进一步深入的请求过程，您可能会陷入深层的无尽管理状态周期;当我得到它和现在之间有信息改变？你所知道的关于这些信息是，如果你被告知它是什么。这对REST流程至关重要;你获得的是底层数据的表示，但是没有错误;该表示不是基础数据，不仅仅是国会*的名字是国会*本人。

其次，不要担心信息的可用性。如果一个对象有一个子对象，当你查询该对象时，查询该子对象。如果你收回数据，太棒了。如果您发现数据不可用，那也是子对象数据的表示;它只是一种与你希望的不同的表现形式，但它同样有效。我将它表示为一个空值的对象;该对象存在（因为它属于父对象而被实例化），但是没有关于它的有效数据（由于某种原因返回的表示是空的;缺少可用性，服务器关闭，数据更改;无论如何）。最后，这里真正的关键是你需要记住一个RESTful结构是由超媒体驱动的;对不返回完整对象数据的对象的请求应返回请求子对象数据的URI;等等。关键在于这些结构不是静态的，就像你的对象结构似乎希望对待它们一样;它们是动态的，并且由服务器决定表示（即相互关系）。试图用提前具体的对象表示法来定义这一点，意味着您正在以一种REST从未被处理的方式来处理系统。