API分類
API按照功能一般可以分為賬戶、交易、行情三類。
調用接口的方式有兩種：REST、WebSocket
REST，即Representational State Transfer（表現層狀態轉換）
Roy Thomas Fielding於2000年提出的一種萬維網軟件架構風格，目的是便於不同軟件/程序在網絡中互相傳遞信息。
REST是根基於超文本傳輸協議(HTTP)之上而確定的一組約束和屬性，是一種設計提供萬維網絡服務的軟件構建風格。
匹配或兼容於這種架構風格(簡稱為 REST 或 RESTful)的網絡服務，允許客戶端發出以統一資源標識符訪問和操作網絡資源的請求，而與預先定義好的無狀態操作集一致化。因此表現層狀態轉換提供了在互聯網絡的計算系統之間，彼此資源可交互使用的協作性質(interoperability)。相對於其它種類的網絡服務，例如 SOAP服務則是以本身所定義的操作集，來訪問網絡上的資源。
三種主流的Web服務實現方案：REST、SOAP、XML-RPC。
REST是設計風格而不是標准。REST通常基於使用HTTP，URI，和XML以及HTML這些現有的廣泛流行的協議和標准。
資源是由URI來指定。
對資源的操作包括獲取、創建、修改和刪除資源，這些操作正好對應HTTP協議提供的GET、POST、PUT和DELETE方法。
通過操作資源的表現形式來操作資源。
資源的表現形式則是XML或者HTML，取決於讀者是機器還是人，是消費web服務的客戶軟件還是web瀏覽器。當然也可以是任何其他的格式，例如JSON。
架構約束
-
客戶-服務器（Client-Server）
通信只能由客戶端單方面發起，表現為請求-響應的形式。 -
無狀態（Stateless）
通信的會話狀態（Session State）應該全部由客戶端負責維護。 -
緩存（Cache）
響應內容可以在通信鏈的某處被緩存，以改善網絡效率。 -
統一接口（Uniform Interface）
通信鏈的組件之間通過統一的接口相互通信，以提高交互的可見性。 -
分層系統（Layered System）
通過限制組件的行為（即每個組件只能“看到”與其交互的緊鄰層），將架構分解為若干等級的層。 -
按需代碼（Code-On-Demand，可選）
支持通過下載並執行一些代碼（例如Java Applet、Flash或JavaScript），對客戶端的功能進行擴展。
關於狀態：應該注意區別應用的狀態和連接協議的狀態。HTTP連接是無狀態的（也就是不記錄每個連接的信息），而REST傳輸會包含應用的所有狀態信息，因此可以大幅降低對HTTP連接的重復請求資源消耗
匹配REST設計風格的Web API稱為RESTful API。它從以下三個方面資源進行定義：
- 直觀簡短的資源地址：URI，比如：http://example.com/resources/。
- 傳輸的資源：Web服務接受與返回的互聯網媒體類型，比如：JSON，XML，YAML等。
- 對資源的操作：Web服務在該資源上所支持的一系列請求方法（比如：POST，GET，PUT或DELETE）。
REST的優點
- 可更高效利用緩存來提高響應速度
- 通訊本身的無狀態性可以讓不同的服務器的處理一系列請求中的不同請求，提高服務器的擴展性
- 瀏覽器即可作為客戶端，簡化軟件需求
- 相對於其他疊加在HTTP協議之上的機制，REST的軟件依賴性更小
- 不需要額外的資源發現機制
- 在軟件技術演進中的長期的兼容性更好
WebSocket API
WebSocket是一種在單個TCP連接上進行全雙工通信的協議。WebSocket通信協議於2011年被IETF定為標准RFC 6455，並由RFC7936補充規范。WebSocket API也被W3C定為標准。
WebSocket使得客戶端和服務器之間的數據交換變得更加簡單，允許服務端主動向客戶端推送數據。在WebSocket API中，瀏覽器和服務器只需要完成一次握手，兩者之間就直接可以創建持久性的連接，並進行雙向數據傳輸。
為了創建Websocket連接，需要通過瀏覽器發出請求，之后服務器進行回應，這個過程通常稱為“握手”（handshaking）。
現在，很多網站為了實現推送技術，所用的技術都是輪詢。輪詢是在特定的的時間間隔（如每1秒），由瀏覽器對服務器發出HTTP請求，然后由服務器返回最新的數據給客戶端的瀏覽器。這種傳統的模式帶來很明顯的缺點，即瀏覽器需要不斷的向服務器發出請求，然而HTTP請求可能包含較長的頭部，其中真正有效的數據可能只是很小的一部分，顯然這樣會浪費很多的帶寬等資源。
而比較新的技術去做輪詢的效果是Comet。這種技術雖然可以雙向通信，但依然需要反復發出請求。而且在Comet中，普遍采用的長鏈接，也會消耗服務器資源。
在這種情況下，HTML5定義了WebSocket協議，能更好的節省服務器資源和帶寬，並且能夠更實時地進行通訊。
Websocket使用ws或wss的統一資源標志符，類似於HTTPS，其中wss表示在TLS之上的Websocket。如：
- ws://example.com/wsapi
- wss://secure.example.com/
Websocket使用和 HTTP 相同的 TCP 端口，可以繞過大多數防火牆的限制。默認情況下，Websocket協議使用80端口；運行在TLS之上時，默認使用443端口。
優點
-
較少的控制開銷-
在連接創建后，服務器和客戶端之間交換數據時，用於協議控制的數據包頭部相對較小。在不包含擴展的情況下，對於服務器到客戶端的內容，此頭部大小只有2至10字節（和數據包長度有關）；對於客戶端到服務器的內容，此頭部還需要加上額外的4字節的掩碼。相對於HTTP請求每次都要攜帶完整的頭部，此項開銷顯著減少了。 -
更強的實時性
由於協議是全雙工的，所以服務器可以隨時主動給客戶端下發數據。相對於HTTP請求需要等待客戶端發起請求服務端才能響應，延遲明顯更少；即使是和Comet等類似的長輪詢比較，其也能在短時間內更多次地傳遞數據。 -
保持連接狀態
與HTTP不同的是，Websocket需要先創建連接，這就使得其成為一種有狀態的協議，之后通信時可以省略部分狀態信息。而HTTP請求可能需要在每個請求都攜帶狀態信息（如身份認證等）。 -
更好的二進制支持
Websocket定義了二進制幀，相對HTTP，可以更輕松地處理二進制內容。 -
可以支持擴展
Websocket定義了擴展，用戶可以擴展協議、實現部分自定義的子協議。如部分瀏覽器支持壓縮等。 -
更好的壓縮效果
相對於HTTP壓縮，Websocket在適當的擴展支持下，可以沿用之前內容的上下文，在傳遞類似的數據時，可以顯著地提高壓縮率。
傳輸控制協議（英語：Transmission Control Protocol，縮寫為TCP）是一種面向連接的、可靠的、基於字節流的傳輸層通信協議，由IETF的RFC 793定義。在簡化的計算機網絡OSI模型中，它完成第四層傳輸層所指定的功能，用戶數據報協議（UDP）是同一層內另一個重要的傳輸協議。
互聯網協議（英語：Internet Protocol Suite，縮寫IPS）是一個網絡通信模型，以及一整個網絡傳輸協議家族，為互聯網的基礎通信架構。它常被通稱為TCP/IP協議族（英語：TCP/IP Protocol Suite，或TCP/IP Protocols），簡稱TCP/IP。因為該協議家族的兩個核心協議：TCP（傳輸控制協議）和IP（網際協議），為該家族中最早通過的標准。
應用層面區別
- REST API更適合進行幣幣交易或者資產提現等操作。
- WebSocket API更適合獲取市場行情和買賣深度等信息。建立一次連接，后續服務器有任何變動，都會實時推送到當前客戶端，適合高頻交易。
原文鏈接：https://blog.csdn.net/The_Time_Runner/article/details/86518448