REST API設計：如何分解API對象以使其更具可擴展性和可靠性API

我們擁有用於移動電話的電子商務網站。我們正在建立寧靜的API，POST，PUT，DELETE，UPDATE手機。REST API設計：如何分解API對象以使其更具可擴展性和可靠性API

每款手機都具有以下基本功能： - 價格，製造商，製造年份，顏色，折扣。

與此同時，大多數手機也會有圖像。

此外其中幾個有製造商保修。可以說他們中的50％。

而且很少有手機可以提供融資選擇，例如我們已經與某些銀行合作以便爲這些貸款提供貸款。幾乎80％將有這個設施。

我們決定設計API此兩種方法：

方法1.所有這些在同一個JSON對象。只有一個API如：

{ 
    "basicInfo": { 
     "price": "", 
     "mfgYear": "", 
     "manufacturer": "" 
    ... 
    }, 
    "images":{...}, 
    "warranty":{...},  
    "finance":{...}  
    }

方法2.將所有這些JSON對象分開。例如：

First Api for "basicInfo". 
    Second Api for "images". 
    Third Api for "warranty". 
    Fourth Api for "finance"

我能想出每個幾利弊：

APPROACH1：優點：我們相聚在服務器上的所有庫存信息。這意味着更少的API命中，更少的服務器負載。此外，將來如果我們實施一些隊列處理以將這些股票信息保存到數據庫中，則在將股票插入數據庫之前不會發布圖像/保修/財務的情況，因爲我們將所有信息放在一起。因此，我們首先將庫存插入數據庫，然後將記錄插入到具有外鍵關係的其他表中。 缺點：此API /資源有多重責任。它會變得越來越大，將來可能會在這個API中有太多的領域。此外，這看起來像違反單一責任原則給我。

APPROACH2：優點：這看起來有點清潔和有組織。看起來每個API都有自己的職責定義。看起來可以擴展到我。如果在一個API中進行更改，則不太可能影響其他API。 缺點：服務器上的API點擊次數更多。在股票發佈前發佈股票依賴資源的可能性更大。例如，我們可能在插入股票之前出隊圖像。

方法3。給出這兩個選項。允許使用基本信息發送其他信息的示例以及爲這些資源創建單獨的API。

哪種方法最好，即更安寧，可擴展，性能更好？

來源

2017-02-20 maverick

只給出你提供的信息，這裏是我設計這個系統的過程。擁有單獨的手機終端，擔保和融資信息。積極緩存保證，因爲這些很少會改變。在手機的JSON表示中包含保修和融資信息的鏈接。 /phones/{phoneId}端點支持名爲「expand」的查詢參數。如果服務器看到expand=warranty,expand=financing或expand=warranty, financing，則除了提供鏈接之外，還將相關的JSON嵌入到電話資源中。現在客戶可以選擇他們需要的信息並獲得它。

對於圖像，如果可能的話使用CDN照顧他們的，只是包括一個鏈接。如果您需要在您的API中管理它們，那麼我會將它們視爲上述保修和融資。確保它們非常積極地緩存，因爲手機看起來不會經常變化。如果您需要更改圖像，請使用新文件名。

這種方法的一個例子可以在規格爲JSON API，其中相關的屬性被稱爲「包括」可以看出。 JSON API對你來說可能太重了，但它有一些好點子，值得瀏覽規格。

最後，注意，這類開放式的問題是比較合適https://softwareengineering.stackexchange.com/。堆棧溢出用於提供正確答案的問題。

來源

2017-02-20 21:46:08

那麼post呢？我想你已經回答了。帖子應該分開還是我們應該只給一個Api？ – maverick

@sahil你真的希望客戶通過'POST'來更新'/ phones'的保修嗎？這對我來說似乎是個壞主意。我會想象，多個手機將分享保修。同樣，如果供應商和產品線相同，則對於多個分立電話來說，融資信息可能是相同的。要求客戶更新這些東西以分開進行。 –

每部手機都會有不同的EMI金額，任期和將提供此服務和其他幾個領域的銀行名稱。現在，我們應該使財務信息的一部分，電話api發佈或保持它作爲單獨的資源？ – maverick

我無親用JSON，但據我所知它可以堆疊這些對象，所以你可以有一個層次的（全）推動的插入/更新，也完成（或預期不完整）GET-調用。

這樣你就不必炸燬每推/拉動作，並且仍然靈活，當談到擴展。您也可以 - 或者很可能想 - 調用專門的例程來插入/更新每個子對象，以便您可以提供並使用這些作爲REST API的一部分。

對於拉動，您可以將缺失的節點標記爲undecided，或者已經針對數據庫進行檢查並標記爲unloaded或not available。

請記住，如果你對所有子對象提供的API（APP.1或3）它總是會到調用者擁有這些電話sorted-尤其是當它涉及到的缺失通常按相反的順序完成。

如果您決定使用複雜的API（1或3），您可以 - 但是 - 仍然可以使用隊列和超時。因此，您可以將請求（主要是寫入）存儲在隊列中，並且在短暫超時之後，將數據轉發到插入/更新（/刪除）例程之前，請檢查隊列。

來源

2017-02-20 21:49:06 RuDevel

方法1：優點：[...]我們將首先將庫存插入到數據庫中，然後將記錄插入到具有外鍵關係的其他表中。

如果你想建立一個強大的API，比去，因爲它會告訴你安全地進行交易的方式。

缺點：此API /資源具有多重責任。它會變得越來越大，將來可能會在這個API中有太多的領域。

您可以減少此檢索required fields only的負面影響。

來源

2017-02-20 22:09:01

我們可以通過在方法2中插入股票之前不允許張貼圖像/財務信息來實現安全交易。你有沒有其他理由支持方法1？ – maverick

這是否意味着API消費者的業務邏輯[遷移]（https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling）？ –

是的。我們也可以做到這一點。 – maverick

REST API設計：如何分解API對象以使其更具可擴展性和可靠性API

回答

相關問題