http協議接口簡單概括接口相對復雜的一個接口示例
2021-10-31
謝謝你的邀請
這里只討論傳統的http協議接口，不考慮各種類庫提供的面向對象接口的簡單總結
簡單的界面示例
一個相對復雜的界面示例
[
[
'name' => 'cat1' ,
'age' => 2 ,
] ,
[
'name' => 'cat2' ,
'age' => 5 ,
] ,
[
'name' => 'cat3' ,
'age' => 2 ,
] ,
] ,
'code' => 1 ,
'msg' => 'the API!' ,
]);
上面一個比較復雜的接口例子有三個字段，data、msg、code。這是一個相對基本的最佳實踐解決方案。實際過程可能會更復雜，返回的數據可能只有這個。
{
"data" : [
{
"name" : "cat1",
"age" : 2
},
{
"name" : "cat2",
"age" : 5
},
{
"name" : "cat3",
"age" : 2
}
],
"code" : 1,
"msg" : "success"
}
需要注意的是，在任何情況下，一旦確定了同一接口的規(guī)范，除非該接口關閉且不提供http服務，否則任何情況下都必須返回符合該規(guī)范的數據。如果服務器異常，則無法返回。正常數據，可以通過code和msg字段告知原因，方便前端調用者自行判斷處理
對于數據字段，這個數組的數據來源大致如下：
json和xml的比較
json之所以比xml應用更廣泛，是因為它的結構化描述數據更輕，使用的字符數更少，更節(jié)省網絡資源。
傳遞相同的數據
json：
{"code":1,"msg":"the API!"}XML：
1
the API!
json格式表示鍵值對，而xml格式可以表示鍵值對以及屬性特征
所以嚴格來說xml和json不能絕對同等轉換，但是可以自定義規(guī)范使用json來表示xml的同義，即xml中的屬性特征。json 中沒有等效的表示
下例中ui:標簽中的屬性需要用類似json中@的方式來描述，可以實現和xml一樣的數據傳輸，但是要明白本質是不等的
XML：
Search
json：
{
"@attributes" : {
"layout" : "vertial"
},
"block" : [
{
"@attributes" : {
"width" : "200",
"layout" : "horizontal"
},
"input" : {
"@attributes" : {
"value" : "Search"
}
},
"button" : "Search"
},
{
"@attributes" : {
"width" : "400"
}
}
]
}一般規(guī)格
該領域的設計規(guī)范沒有特別的標準，通常是為了確保在一個項目或一個團隊中的一致性
但這還遠遠不夠。為了有一套規(guī)范，可供行業(yè)內不同團隊、不同項目使用，一些大公司編寫了通用規(guī)范。如果他們都遵守，溝通起來會更方便，減少分歧。項目中的溝通成本
前面說了，因為xml幾乎已經被json取代了，這個協議幾乎成了一個傳說，個人覺得沒必要學
這是一套比較復雜的規(guī)范，它帶來的好處是它在規(guī)范內的表達能力非常突出。
通俗地說，現在我想用php，或go，或javaphp接口開發(fā)，或任何語言，調用另一個用php，或go，或java，或任何其他語言編寫的函數或對象方法。如何實現？是的，不管你用什么語言，只要你在編碼中遵循這套規(guī)范，那么你就可以達到這個要求
這個規(guī)范是soap的json版本，但它不僅是對數據傳輸的打包方式的替代，而且它的規(guī)范比soap的內容簡單很多，所以優(yōu)點是使用起來非常靈活，而且數據傳輸過程節(jié)省了網絡資源。建議學習
另外php接口開發(fā)，還有一個比較時髦的東西叫，詳情請看這里
WEB開發(fā)中，使用JSON-RPC好還是API好？
談談緩存
在討論這個問題之前，我們首先要了解一件事，就是獲取我們需要的數據時服務器開銷的大小。
上面我們提到，大部分數據來自數據庫，或者第三方接口返回的數據，聽起來還可以，但遺憾的是這兩種獲取數據的方式都會有比較大的性能開銷。
在數據庫中查詢時，數據庫會操作硬盤，這對系統來說是一個很大的開銷，尤其是在查詢連接表時，開銷幾乎呈幾何級數增長。
請求第三方接口時，會發(fā)送網絡請求。如果對方接口有頻率限制或者網絡環(huán)境不穩(wěn)定，會直接導致接口穩(wěn)定
當然，我們的開發(fā)不會有任何“慢”或“卡”的感覺。畢竟對于人來說，0.01秒和0.秒基本沒有區(qū)別，但是如果考慮并發(fā)，當一個操作重復1w、10w次的時候，這個開銷是必須要考慮的，所以必須考慮緩存
前面提到的緩存方法（、、、、、DB、、H2等）都有一個共同的特點，就是讀取其中數據的系統開銷比之前的數據庫或者第三方庫或者其他方法要小。通常的做法是將數據直接存儲在內存中。讀取過程不需要操作硬盤，直接從內存中讀取。因此，速度和成本都優(yōu)于以前的方法。鑒于此，必須考慮緩存
是不是所有的接口都需要緩存？不必要。
通常最基本的原則是不經常變化的數據需要考慮，而經常變化的數據需要專門評估
通常最基本的做法是在接口邏輯中先讀取緩存數據，如果沒有讀取緩存數據，則請求數據庫，如果數據請求成功，則先緩存數據，然后返回數據
下次請求此接口時，將首先讀取緩存。這時候上次緩存的數據已經在緩存中了，直接從緩存中取出數據返回。這樣就避免了對數據庫的請求，達到了減輕數據庫壓力的目的。
這種邏輯導致的問題是，更新數據庫中的數據時，需要使相應的緩存失效。如何掌握使相應緩存失效的時機是一個比較重要的知識。通常，更簡單粗暴的做法是指定緩存過期時間。在要求較高的系統中，需要特殊的方式來處理，這里不再贅述。
原諒我偷懶，這篇文章值得參考
Star Boy：緩存穿透、緩存崩潰、緩存雪崩原因+解決方案
常用的有,,,, DB,, H2等。
其中是純內存緩存，不能持久化數據，可以緩存的數據類型比較有限，性能也是最優(yōu)秀的
支持更豐富的數據類型，數據可以持久化到硬盤，建議考慮
其他未實戰(zhàn)使用的緩存軟件暫不評論
以上
