API接口設計 - 切換或2個不同的接口

我正在學習接口設計。API接口設計 - 切換或2個不同的接口

這是我很好奇的。

一些開放的API支持2個不同的接口來實現切換。即instagram like接口。它分離一樣的界面（如，取消等）
什麼是獨立的這兩個優勢。（分離成兩個接口，使最終用戶更加複雜在我看來）

我懷疑這一點，因爲它可能通過切換來實現。

即用戶發送item_id和user_id。服務器檢查數據庫（這個項目已經被喜歡或不喜歡），並更新。

感謝您的回答！

來源

2016-01-13 Juneyoung Oh

有兩個接口切換的真正好處是它不需要用戶知道他們試圖改變的事物的當前狀態（即它不需要我首先查詢狀態）。

如果我是API的消費者，通常我會執行諸如like之類的操作。我很少能想到一個我想要執行do the opposite of what I did previously（除非我感覺像翻轉屏幕一樣）動作的情況。如果您沒有like和unlike的兩個端點，那麼您首先必須輪詢API以獲取當前狀態，然後根據需要執行您正在討論的切換。

這種情況會在代碼中引入更多邏輯，要求您對API進行1-2次調用，並假定狀態在調用之間沒有變化;而擁有兩個端點則會減少邏輯，將您的API調用限制爲每個操作1個，並且您不必擔心狀態意外更改。

如果您嘗試like某些用戶已有like d的情況，那麼API將簡單地返回成功的結果並且不會更改基礎數據。

來源

2016-01-13 01:44:01 Suever

感謝您的回答。這是非常有說服力的。但是，我仍然有一個問題。我會適用於具體情況，喜歡和取消。作爲一個終端用戶，如果它使用單獨的API，我必須每次檢查視圖的狀態。另一方面，如果它使用一個切換API，我會調用相同的API而不檢查 - 也許檢查當前狀態不是爲最終用戶。（我的前提下，像API的關鍵是USER_ID和media_id）由於這個API與特定用戶捆綁，我覺得我不關心狀態變化。對於類似'like'這樣的操作，我仍然沒有獲得獨立API的優勢。謝謝 –

我不完全確定你的意思是「每次檢查視圖的狀態」。您不必這樣做，因爲即使該項目已經是'like'd，API也會接受您的'like'動作。它會默默地不改變價值。我已經更新了我的回答以澄清。 – Suever

我的圖像存儲Instagram的數據庫（因爲管理員用戶要篩選一些散列標籤的結果）。然後，一個門戶用戶來到網站，並希望做「像」行動。所以他按下按鈕（這個按鈕是設計切換文字在'like'和'cancel'之間切換）。在這種情況下，開發人員必須檢查當前的按鈕文本並調用instagram API，因爲「like」和「cancel like」是不同的。 //這是我在「每次查看視圖狀態」時的意思。不過，我明白了你的觀點 –

偏好一個接口的一個原因是，它將是冪等的。也就是說，即使請求被多次執行，結果狀態也是一樣的。

這是一個相當人爲的例子，但如果兩個不同的人共享同一帳戶試圖喜歡一個足夠小的窗口中同樣的事情，你可以用它作爲聯合國喜歡，而不是結束。

來源

2016-01-13 01:50:01 mzulch

API接口設計 - 切換或2個不同的接口

回答

相關問題