介面、資料結構、資訊架構的區別

繼上篇關於介面的文章，再來寫一下介面、資料結構、資訊架構的區別。

以簡書為例，簡書裡有文章、專題、使用者，它們是不同的東西，這很好理解。而在開發層面，文章、專題、使用者，它們分別是一種資料物件。

比如文章這種物件，包含了標題、正文內容，也有字數、閱讀數、喜歡數等等。或許還有一些沒有向使用者展示，但也會實際存在的資料，比如這篇文章被收藏了幾次，可能也記錄了下來，只是產品設計上沒有被我們看到。

那麼文章這個資料物件，它的資料結構就可以表示為：

{
  id: 1000,
  created_at: Fri, 11 Aug 2017 08:43:38 CST +08:00,
  shared_at: Fri, 11 Aug 2017 08:52:48 CST +08:00,
  last_updated_at: Fri, 11 Aug 2017 08:52:48 CST +08:00,
  wordage: 1000,
  view_count: 10000,
  likes_count: 2,
  title: 'xxxxx',
  ...
}

資料結構是計算機儲存、組織資料的方式。

實際中，業務越複雜，資料物件越多、資料結構也越複雜，一個物件可能包含有非常多的資訊。如果我們在每個需要展示這些資料的地方，都去取所有的資料，這並不現實。資料太多會影響載入速度，沒這個必要，也不安全。

比如某個文章列表，我們只要標題、釋出時間、封面圖、閱讀數、喜歡數、評論數，這些資訊就足夠了。介面就是幹這件事的，它約定了某個介面可以拿哪些資料。

應用程式設計介面，是軟體系統不同組成部分銜接的約定。

不同的地方用不同的介面，這樣不會互相影響。有時為了快速上線需求，也會共用一些介面，節省服務端的工作量。實際上，介面也有版本之分，用來給新老版本呼叫，實現過渡。

開發部門內部會有介面文件，服務端工程師會把有哪些介面、怎麼使用介面給記錄下來，讓客戶端工程師查閱使用。

至於資訊結構，雖然聽起來跟資料結構有點像，但資訊結構其實不是開發裡的概念，而是互動設計、產品設計裡的概念。

資訊架構是指對某一特定內容裡的資訊進行統籌、規劃、設計、安排等一系列有機處理的想法。

比如一個 App，包含了首頁、搜尋、訊息這些板塊，首頁這個版本又包含了廣告 banner、運營入口、資訊流等等。這可以全域性性地梳理一個產品，也是研究競品的常見方式。