上篇《.net core實踐系列之短信服務-架構設計》介紹了我對短信服務的架構設計，同時針對場景解析了我的設計理念。本篇繼續講解Api服務的實作過程。
源碼位址：https://github.com/SkyChenSky/Sikiro.SMS
此服務會使用.NET Core WebApi進行搭建，.NET Core WebApi基礎原型就是RESTful風格，然而什麼叫RESTful呢。
Representational State Transfer的縮寫，翻譯為“表現層狀态轉化”，是由Roy Thomas Fieding在他的博士論文《Architectural Styles and the Design of Network-based Software Architectures》中提出的一種架構思想。
而他的論文中提出了一個RESTful應用應該具備的幾點限制。
每個資源都應該有一個唯一的辨別
每一個對象或資源都可以通過一個唯一的URI進行尋址，URI的結構應該是簡單的。
使用标準的方法來更改資源的狀态
GET、POST、PUT、PATCH、DELETE
Request和Response的自描述
資源多重表述
URI所通路的每個資源都可以使用不同的形式加以表示（XML或JSON）
無狀态的服務
不需要儲存會話狀态（SESSION），資源本身就是天然的狀态，是需要被儲存的。
當某Web服務遵守了REST這些限制條件和原則，那麼我們可以稱它設計風格就是 RESTful。
REST有三大特點：
資源（名詞）
動作（動詞）
表述（超文本）
抽象的說他可以是音頻、也可以是視訊，更可以是訂單。更俗講其實就是實體，更接*我們*常說的“類（class）”。另外REST強調資源有唯一的URI。下面有對比
主要動作：
GET：檢索單個資源；
POST：主要是建立資源，但是GET的參數長度受限，是以也可以用在複雜參數的檢索資源場景；
PUT：更新資源所有屬性，也可以稱為替換資源；
PATCH：更新資源部分屬性；
DELETE：删除資源；
對于Request與Response的自描述，而表述方式有多種：XML、JSON等，強調HTTP通信的語義可見性。
SMSApi.com/api/GetSMS
SMSApi.com/api/CreateSMS
傳統的接口設計面向過程的，每個動作有特定的URI。
SMSApi.com/api/SMS GET
SMSApi.com/api/SMS POST
REST API每個資源隻有唯一的URI，而資源可以有不同的動作執行相應的接口
RPC的更加傾向于面向過程，而RESTful則以面向對象的思想進行設計。
回到我們的短信服務，以上面的三特點進行出發，SMS不需要由外部服務進行删除、修改資源是以：
資源：SMS
動作：GET、POST
表述方式：我們約定Request、Response為JSON格式
由上可見一共定義了三個接口
GET http://localhost:port/api/sms/id 擷取一條短信記錄
POST http://localhost:port/api/sms 發送短信
POST http://localhost:port/api/sms/_search 查詢短信記錄
擷取一條短信記錄就不多解析了
動作我使用了POST，有人會問檢索資源不是用GET麼？對，但是GET的參數在URL裡是受限的，是以在複雜參數的場景下應該選擇POST，然而我是模仿elasticsearch的複雜查詢時定義，添加多一個節點/_search申明此URI是做查詢的。
此接口的實作邏輯主要兩件事，持久化到MongoDB，過濾出及時發送的短信記錄發送到RabbitMQ。
在持久化之前我做了一個分頁的動作，我們提供出去的接口，同一條短信内容支援N個手機号，但是不同的短信營運商的所支援一次性發送的手機數量是有限的。
開始實作時，我把分頁發送寫到隊列消費服務的發送短信邏輯裡，但是這裡有個問題，如果分頁後部分發送成功，部分發送失敗，那麼這個聚合究竟以失敗還是成功的狀态标示呢？換句話來說我們無法保證聚合内的資料一緻性。
是以我的做法就是優先在分頁成多個文檔存儲，那麼就可以避免從資料庫取出後分頁導緻部分成功、失敗。
EasyNetQ
EasyNetQ.DI.Microsoft
Sikiro.Nosql.Mongo
log4net
Mapster
這個開源架構是針對RabbitMQ.Client的封裝，隐藏了很多實作細節，簡化使用方式。并提供了多種IOC注入方式
源碼位址：https://github.com/EasyNetQ/EasyNetQ
這個是我自己針對mongo驅動的常用的基礎操作的封裝庫
源碼位址：https://github.com/SkyChenSky/Sikiro.Nosql.Mongo
實體映射架構，看評測資料比AutoMapper等之類的效率要高，而且易用性也非常高。
https://github.com/MapsterMapper/Mapster
上面的WriteToFile是我對Exception的擴充方法，使用了Log4Net日志架構對異常進行記錄，如果有需要也可以寫到mongodb或者elasticsearch
架構與工具庫都是以庫的形式提供我們使用，而且都是可複用，但是他們差別在于：工具庫開箱即用，大多數以靜态方法提供調用，隻調用少量甚至一個方法則完成使用。
而架構定義，為了實作某個軟體元件規範時，提供規範所要求之基礎功能的軟體産品，而他具有限制性、可複用性、規範性。他是一個半成品，可重寫。
是以為了簡化架構的使用，對常用設定、建構組合進行封裝，以一個擴充類或者幫助類的形式提供，簡化使用、增加可讀性。
Http協定的好處是輕量、跨*台，如此良好的靈活性然而需要接口描述對外暴露。Swagger是一個很好的選擇，不需要自己手寫文檔并提供背景管理界面，還可以測試，簡化不少工作。
我選擇了NSwag.AspNetCore開源元件，他的使用非常簡單。隻需要兩步：
此設定為了把接口、參數注釋顯示到Swagger頁面
NSwag還有多個版本的UI選擇：
UseSwaggerReDoc
UseSwaggerUi
UseSwaggerUi3
通路http://localhost:port/swagger就可以見到API文檔了
因為我公司還是使用windows server 2008。是以部署前應準備環境安裝包：
.NET Core 2.1.3 windows-hosting
安裝完成後重新開機伺服器，再把檔案釋出到伺服器，編輯應用程式池為無托管代碼。就可以通路了
本篇介紹Sikiro.SMS.Api的設計與實作，下篇會針對API調用進行封裝SDK。如果有任何建議，請在下方評論回報給我。
作 者：
陳珙
出 處：http://www.cnblogs.com/skychen1218/
關于作者：專注于微軟平台的項目開發。如有問題或建議，請多多賜教！
版權聲明：本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連結。
聲援部落客：如果您覺得文章對您有幫助，可以點選文章右下角推薦一下。您的鼓勵是作者堅持原創和持續寫作的最大動力！