如何通過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從未被處理的方式來處理系統。