以下內容來自
這裡只說一下對sp提供的移動通道的介面呼叫的方法。希望能給一些沒有涉及這些內容的朋友提供一些幫助。
首先說一下使用者上行，上行就是指手機使用者編輯簡訊到指定的號碼的過程，我們在web開發中針對使用者上行內容的處理流程是這樣：
手機使用者編輯簡訊到指定的號碼--------------》(傳輸到移動閘道器)------->移動閘道器在收到這條資訊，並處理完後把處理結果返回到合作方(一般這裡是sp)的閘道器------->sp的閘道器收到這條上行處理後再把結果傳輸到我們最下層的合作方-------》到這裡我們就可以寫出我們的處理介面實現對應的資料處理或者簡訊下發。
web開發員------》呼叫sp的移動下發介面，（一般是進行事前的資料處理，然後再配置下發的引數）-----》呼叫sp的介面後，sp的介面會進行響應的資料記錄，然後把內容提交到移動的閘道器------》移動閘道器再把內容下發給使用者----》下發操作執行後，移動閘道器將相應的狀態報告再回發給sp的介面------》sp的介面再通知我們的響應處理介面。
流程基本上是以上的內容。在實際操作的過程中還會出現掉包的情況，畢竟資料通過幾個中轉，大資料量併發的狀態下肯定會掉包，所以也有個掉包率的概念。另外web開發者需要與sp的技術中心進行一些協調，比如我們需要從sp那邊獲取sp為我們分配的業務編號，以及指令和位址碼這類資訊，以及我們還需要提供給sp一些我們的響應介面(響應介面的開發需按照的sp的開發手冊來進行開發，每家的sp在這裡會有一些不同),比如使用者上行後，sp的閘道器收到這個報告後，就需要繫結乙個我們的響應介面，來對上行內容進行一些操作。
注意：移動增值類的業務主要分為三個，點播，按條定製，包月定製。
點播：就是使用者上行一條資訊，扣一次錢。另外針對點播業務，使用者上行後會產生乙個隨機的linkid，當我們給使用者下發的時候必須以這個linkid來為這個手機號下發內容，負責使用者上性的這條資訊就不會扣錢，也就是說只有我們通過這個產生的linkid，並為使用者下發了內容以後，移動才能夠收取手機使用者的錢。
按條定製：當使用者訂製了這個業務時，系統將會每天自動會使用者下發幾條內容，每下發成功就會扣一條資訊的錢。現在有很多手機交費的**就會採用這個業務，當使用者傳送了訂製指令後，sp的通道就會為使用者下發指定條數的資訊，以此來收取費用，下發30條，就收你30塊。
下面為大家簡單介紹乙個類似的通道呼叫(具體的sp介面每家都有些不同，但基本是大同小異)
下發介面(以簡訊下發介面為例)：
引數注釋：
serviceid為業務id 由sp提供
to ：接受方手機
from：傳送方號碼，由sp提供 比如 1861
linkid: 使用者上行後產生的linkid，可以從使用者上行的簡訊中，或者從sso介面獲得。（linkid是有有效期的，超過有效期將會失效）
msg:為我們下發的手機內容。
其它的介面就不一一舉例了。關鍵是掌握這些流程，和原理。
AWVS 提供的介面
api auth 認證 api listloginseq 認證 api listprofiles 檢視掃瞄配置 api listreports 檢視報表 api listscans 檢視掃瞄任務 api listsettings 掃瞄配置 api listtemplates api addscan ...
提供給外部呼叫的介面設計原則
1 介面入參 出參和介面名應擁有統一的命名規範，要做到見名知意。2 不要做大而全的介面，要盡量保持介面的功能單一 好處 這樣有利於介面除錯 改造公升級和維護 3 介面出參應含有介面呼叫結果資訊 code 和 message 字段 4 介面出參應對同型別 單條，多條，分頁 的資料有固定相同的格式 好處...
移動通訊網路中的通道
傳輸通道 邏輯通道 通道的對映 通道 無線通道是對無線通訊中傳送端和接收端之間通路的一種形象比喻，對於無線電波而言，它從傳送端傳送到接收端，其間並沒有乙個有形的連線，它的傳播路徑也有可能不只一條，我們為了形象地描述傳送端與接收端之間的工作，可以想象兩者之間有乙個看不見的道路銜接，把這條銜接通路稱為通...