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