我的问题是我正在处理RESTful API，它返回有关对象的信息，在编写类来表示它们时，我不确定如何最好地处理每个变量可用性状态的所有可能性。据我所知，有5种可能性：信息
因此，使用这些，让对象用值或null表示其数据不会削减它。举一个更具体的例子，我正在使用关于美国国会的API，所以问题就是这样：
我要求提供有关法案的信息，其中包含有关赞助立法者的存根。 我最终需要请求有关该立法者的所有信息。并非所有立法者都拥有所有信息。众议院的议员将不会参议院（参议员的六年任期是错开的，所以三分之一每两年到期，众议院每两年完全重新当选）。有些人不会有推特ID，只是因为他们没有。当然，如果我已经要求提供信息，我不应该再次申请。
我看到了几个选项：
我可以创建一个立法者对象并用我所拥有的信息填充它，但是我必须有一些跟踪getter和setter的信息可用性的机制。这就是我现在正在做的事情，但它需要很多的重复代码。
我可以为缩写对象创建一个单独的类，并在我使用不可变的“完整”对象获取更多内容时替换它们，但是我必须非常小心地将所有引用替换为它们并且还要通过一堆不可用的，特别是不适用的信息。
所以，我只是想知道其他人对这个问题的看法。还有其他（更好的）方法来处理这种复杂性吗？不同方法有哪些优点和缺点？在选择方法时我应该考虑什么？
[注意：我在Objective-C工作，但这并不一定是针对该语言的。]
答案 0 :(得分：1)
如果您希望将这些远程资源视为客户端上的对象，那么请大家帮个忙，忘掉REST的流行语。你会让自己疯狂。只需接受您正在执行HTTP RPC并继续进行任何其他RPC项目。
但是，如果你真的想做REST，你需要了解REST缩写词的“State Transfer”部分是什么意思，你需要阅读有关HATEOAS的内容。对于建立客户来说，这是一个巨大的心理转变，但它确实有很多好处。但也许你不需要那些特别的好处。
我所知道的是，如果您尝试使用“REST API”通过线路检索对象，您将得出REST是load of crap的结论。
答案 1 :(得分：0)
这是一个有趣的问题，但我认为你可能会过度思考这一点。
首先，我认为你在考虑信息的可能状态有点过分;考虑您要么拥有这些信息还是没有信息的更基本的考虑因素。为什么你有这些信息并不重要，除了一个案例。让我解释;如果某个法案或立法者或任何事情的信息不适用，您不应该要求它/需要它。那个＆＃34;州＆＃34;是无关紧要的。同样，如果信息处于被请求的过程中，那么它根本就不可用;你真正关心的唯一一个状态是你是否有这些信息，或者你是否还没有这些信息。
如果您开始担心请求流程的进一步深入，您可能会陷入深入，无休止的管理状态循环;我得到它和现在之间的信息有变化吗？如果你被告知它是什么，你所知道的所有信息。这是REST过程的基础;你获得了基础数据的代表，但是没有错误;表示不是基础数据，国会议员的名字本身就是国会议员。
其次，不要担心信息的可用性。如果对象具有子对象，则在查询对象时，查询子对象。如果你收到数据，那很好。如果您回到数据不可用，那也是子对象数据的表示;它只是一个与你所希望的不同的代表，但它同样有效。我将其表示为具有空值的对象;对象存在（已实例化，因为它属于父对象），但您没有关于它的有效数据（由于某种原因返回的表示为空;缺少可用性，服务器关闭，数据已更改;无论如何）。
最后，真正的关键是你需要记住RESTful结构是由超媒体驱动的;对不返回完整对象数据的对象的请求应返回用于请求子对象数据的URI;等等。这里的关键是那些结构不是静态的，就像你的对象结构似乎希望对待它们一样;它们是动态的，并且由服务器决定表示（即相互关系）。试图用一个具体的对象表示来提前定义，这意味着你以一种从未打算处理REST的方式来处理系统。