當客戶端在 發(fā)出POST請求時/albums，您希望將請求正文中描述的專輯添加到現(xiàn)有專輯數(shù)據(jù)中。
成都創(chuàng)新互聯(lián)憑借在網(wǎng)站建設(shè)、網(wǎng)站推廣領(lǐng)域領(lǐng)先的技術(shù)能力和多年的行業(yè)經(jīng)驗，為客戶提供超值的營銷型網(wǎng)站建設(shè)服務(wù)，我們始終認為：好的營銷型網(wǎng)站就是好的業(yè)務(wù)員。我們已成功為企業(yè)單位、個人等客戶提供了網(wǎng)站設(shè)計制作、成都網(wǎng)站制作服務(wù)，以良好的商業(yè)信譽，完善的服務(wù)及深厚的技術(shù)力量處于同行領(lǐng)先地位。
為此，您將編寫以下內(nèi)容：
1、編寫代碼
a.添加代碼以將專輯數(shù)據(jù)添加到專輯列表。
在此代碼中：
1）用于Context.BindJSON 將請求正文綁定到newAlbum。
2） album將從 JSON 初始化的結(jié)構(gòu)附加到albums 切片。
3）向響應(yīng)添加201狀態(tài)代碼，以及表示您添加的專輯的 JSON。
b.更改您的main函數(shù)，使其包含該router.POST函數(shù)，如下所示。
在此代碼中：
1）將路徑中的POST方法與 /albumspostAlbums函數(shù)相關(guān)聯(lián)。
使用 Gin，您可以將處理程序與 HTTP 方法和路徑組合相關(guān)聯(lián)。這樣，您可以根據(jù)客戶端使用的方法將發(fā)送到單個路徑的請求單獨路由。
a.如果服務(wù)器從上一節(jié)開始仍在運行，請停止它。
b.從包含 main.go 的目錄中的命令行，運行代碼。
c.從不同的命令行窗口，用于curl向正在運行的 Web 服務(wù)發(fā)出請求。
該命令應(yīng)顯示添加專輯的標題和 JSON。
d.與上一節(jié)一樣，使用curl檢索完整的專輯列表，您可以使用它來確認添加了新專輯。
該命令應(yīng)顯示專輯列表。
當客戶端向 發(fā)出請求時GET /albums/[id]，您希望返回 ID 與id路徑參數(shù)匹配的專輯。
為此，您將：
a.在您在上一節(jié)中添加的函數(shù)下方postAlbums，粘貼以下代碼以檢索特定專輯。
此getAlbumByID函數(shù)將提取請求路徑中的 ID，然后找到匹配的專輯。
在此代碼中：
（1）Context.Param用于從 URL 中檢索id路徑參數(shù)。當您將此處理程序映射到路徑時，您將在路徑中包含參數(shù)的占位符。
（2）循環(huán)album切片中的結(jié)構(gòu)，尋找其ID 字段值與id參數(shù)值匹配的結(jié)構(gòu)。如果找到，則將該album結(jié)構(gòu)序列化為 JSON，并將其作為帶有200 OK HTTP 代碼的響應(yīng)返回。
如上所述，實際使用中的服務(wù)可能會使用數(shù)據(jù)庫查詢來執(zhí)行此查找。
（3）如果找不到專輯，則返回 HTTP 404錯誤。
b.最后，更改您的main，使其包含對router.GET的新調(diào)用，路徑現(xiàn)在為/albums/:id ，如以下示例所示。
在此代碼中：
（1）將/albums/:id路徑與getAlbumByID功能相關(guān)聯(lián)。在 Gin 中，路徑中項目前面的冒號表示該項目是路徑參數(shù)。
a.如果服務(wù)器從上一節(jié)開始仍在運行，請停止它。
b.在包含 main.go 的目錄中的命令行中，運行代碼以啟動服務(wù)器。
c.從不同的命令行窗口，用于curl向正在運行的 Web 服務(wù)發(fā)出請求。
該命令應(yīng)顯示您使用其 ID 的專輯的 JSON。如果找不到專輯，您將收到帶有錯誤消息的 JSON。
恭喜！您剛剛使用 Go 和 Gin 編寫了一個簡單的 RESTful Web 服務(wù)。
本節(jié)包含您使用本教程構(gòu)建的應(yīng)用程序的代碼。
1 接口的定義與理解
接口是一個自定義類型，它是一組方法的集合。從定義上來看，接口有兩個特點。第一，接口本質(zhì)是一種自定義類型，因此不要將golang中的接口簡單理解為C++/Java中的接口，后者僅用于聲明方法簽名。第二，接口是一種特殊的自定義類型，其中沒有數(shù)據(jù)成員，只有方法（也可以為空）。
接口是完全抽象的，因此不能將其實例化。然而，可以創(chuàng)建一個其類型為接口的變量，它可以被賦值為任何滿足該接口類型的實際類型的值。接口的重要特性是：
（1）只要某個類型實現(xiàn)了接口要的方法，那么我們就說該類型實現(xiàn)了此接口。該類型的值可以賦給該接口的值;
（2）作為1的推論，任何類型的值都可以賦值給空接口interface{}
注意：這只是golang中接口的特性，為非所有類型的特性（接口是一種特殊的類型）。
接口的特性是golang支持鴨子類型的基礎(chǔ)，即“如果它走起來像鴨子，叫起來像鴨子（實現(xiàn)了接口要的方法），它就是一只鴨子（可以被賦值給接口的值）”。憑借接口機制和鴨子類型，golang提供了一種有利于類、繼承、模板之外的更加靈活強大的選擇。
2 例子
type Exchanger interface {
exchange()
}
type StringPair struct {
first, second string
}
type Point[2]int
func (sp *StringPair) exchange() {
sp.first, sp.second = sp.second, sp.first
}
func (p *Point) exchange() {
p[0], p[1] = p[1], p[0]
}
func exchangeThese(exchangers ...Exchanger) {
for _, exchanger := range exchangers {
exchanger.exchange()
}
}
func main() {
pair1 := StringPair{"abc","def"}
pair2 := StringPair{"ghi","jkl"}
point := Point{5, 7}
fmt.Println(pair1, pair2, point)
pair1.exchange()
pair2.exchange()
point.exchange()
fmt.Println(pair1, pair2, point)
// exchangeThese(pair1, pair2) //wrong
exchangeThese(pair1, pair2)
fmt.Println(pair1, pair2)
}
運行結(jié)果
在本例中，自定義類型StringPair和Point指針實現(xiàn)了接口Exchanger所需的方法，因此該類型的值可以被賦值給接口的值。
另外，特別注意一點。如果使用exchangeThese(pair1,
pair2)會導(dǎo)致編譯錯誤（如下圖），正確寫法應(yīng)當是exchangeThese(pair1,
pair2)。這是由于真正滿足接口Exchanger的類型是StringPair指針，而非StringPair。
在golang中，值接收者和指針接收者的方法集是不同的。只是golang會智能地解引用和取引用，使得二者的方法集看上去是一樣的。但是，在調(diào)用exchangeThese時，就凸顯出二者的不同了。
在正常的測試中，當我們需要進行接口測試時，通常使用接口調(diào)試工具，如postman進行接口測試
目前我在嘗試使用Go語言進行接口測試，使用的庫均為Go自帶的庫。
注：當前采用的接口為時事新聞接口，每天可以請求100次，需要的同學(xué)，可以自行使用。
之前寫過了Grpc服務(wù)開發(fā)和接口測試初探【Java】，中間耽擱了一些時間，Go版本的gRPC測試開發(fā)實踐才有時間學(xué)習(xí)使用。其中也是由于自己Go語言不夠熟悉導(dǎo)致的。之前有段時間想暫時放棄Go語言的學(xué)習(xí)，導(dǎo)致了Go的生疏，原因是從Groovy到Java性能。
回歸正題，Go語言版本的gRPC實踐相對Java來說是比較簡單的，但是總體的工具鏈是比較復(fù)雜的，可能是因為Go生態(tài)目前相比Java還是比較匱乏吧。下面我先簡述一下大致的步驟：
以上步驟親自操作可能會遇到一些小問題，我本人搜到的教程什么的也是亂七八糟，踩了一些坑。我沒有整理出一個親自實踐之后的可行的教程，原因有二：
Go語言的gRPC的 proto 編寫跟Java大致一致，只有一個報名的參數(shù)不太一樣。下面是我的 Hello.proto 內(nèi)容：
這里主要 go_package 網(wǎng)上搜到的配置方式有些不一樣，我沒有全都嘗試，大家在搜索的資料時候，盡量先看看 syntax 這個參數(shù)的值，以及文章教程寫作的時間，如果距離現(xiàn)在太久了，我建議直接關(guān)掉。搜索引擎有過濾功能，可以過濾掉過時的教程。
這里Go語言gRPC的一點優(yōu)勢，就是在一個項目中即可實現(xiàn)，Java需要先弄一個SDK這樣。Go語言的gRPC的代碼可以通過生成代碼命令中的參數(shù)實現(xiàn)指定路徑。我是放在了和 proto 文件的同級目錄。
服務(wù)端代碼也是比較格式化的內(nèi)容，如下：
其中 pb.RegisterHelloServiceServer(s, Ser{}) 如果報錯，請檢查自己安裝的工具 protoc-gen-go 或者 protoc-gen-gofast 版本，一般提取報錯 message 搜索也能得到解決辦法。
下面是客戶端的代碼，由于學(xué)藝不精，其中大部分參數(shù)的含義目前我也不是很清楚，特別是基于 stream 的請求響應(yīng)的方式使用。后面我先把Java的學(xué)完，再回過頭來看Go的，按照這個順序?qū)W習(xí)和分享。
服務(wù)端輸出：
忘記打日志了。沒有輸出
客戶端輸出：
Go語言的gRPC測試開發(fā)實踐已經(jīng)完事兒，大概率上我不會在工作中使用Go作為主力gRPC測試語言，后面測試實踐內(nèi)容還是會以Java為主。
所謂Go語言式的接口，就是不用顯示聲明類型T實現(xiàn)了接口I，只要類型T的公開方法完全滿足接口I的要求，就可以把類型T的對象用在需要接口I的地方。這種做法的學(xué)名叫做Structural Typing，有人也把它看作是一種靜態(tài)的Duck Typing。除了Go的接口以外，類似的東西也有比如Scala里的Traits等等。有人覺得這個特性很好，但我個人并不喜歡這種做法，所以在這里談?wù)勊娜秉c。當然這跟動態(tài)語言靜態(tài)語言的討論類似，不能簡單粗暴的下一個“好”或“不好”的結(jié)論。
我的觀點:
Go的隱式接口Duck Typing確實不是新技術(shù), 但是在主流靜態(tài)編程語言中支持Duck Typing應(yīng)該是很少的(不清楚目前是否只有Go語言支持).
靜態(tài)類型和動態(tài)類型雖然沒有絕對的好和不好, 但是每個都是有自己的優(yōu)勢的, 沒有哪一個可以包辦一切. 而Go是試圖結(jié)合靜態(tài)類型和動態(tài)類型(interface)各自的優(yōu)勢.
那么就從頭談起：什么是接口。其實通俗的講，接口就是一個協(xié)議，規(guī)定了一組成員，例如.NET里的ICollection接口：
public interface ICollection {
int Count { get; }
object SyncRoot { get; }
bool IsSynchronized { get; }
void CopyTo(Array array, int index);
}
這就是一個協(xié)議的全部了嗎？事實并非如此，其實接口還規(guī)定了每個行為的“特征”。打個比方，這個接口的Count除了需要返回集合內(nèi)元素的數(shù)目以外，還隱含了它需要在O(1)時間內(nèi)返回這個要求。這樣一個使用了ICollection接口的方法才能放心地使用Count屬性來獲取集合大小，才能在知道這些特征的情況下選用正確的算法來編寫程序，而不用擔(dān)心帶來性能問題，這才能實現(xiàn)所謂的“面向接口編程”。當然這種“特征”并不但指“性能”上的，例如Count還包含了例如“不修改集合內(nèi)容”這種看似十分自然的隱藏要求，這都是ICollection協(xié)議的一部分。
最近寫了個kafka的接收消息的功能，需要使用回調(diào)處理收到的消息。
一個是基本的回調(diào)，一個是使用接口功能實現(xiàn)回調(diào)，對接口是個很好的學(xué)習(xí)。
1.正?；卣{(diào)
kafka的接收消息處。收到消息后，使用傳入的Onmessage進行處理。
調(diào)用kafka接收消息的單元，并在調(diào)用方寫好回調(diào)
在調(diào)用方實現(xiàn)回調(diào)需要執(zhí)行的方法
感覺還是使用基本回調(diào)相對簡單點，接口就當學(xué)習(xí)了。
另外跨包的接口的方法要大寫！定位了好久發(fā)現(xiàn)個入門的問題。
重慶分公司
重慶分公司
