一、接口規則：
| 傳輸方式 | 爲保證交易安全性，建議採用HTTPS傳輸 |
|---|---|
| 提交方式 | 採用HTTP協議中的方法提交 |
| 數據格式 | 提交和返回數據都爲json格式 |
| 字符編碼 | 統一採用UTF-8字符編碼 |
| 簽名算法 | MD5 |
| 簽名要求 | 請求和接收數據均需要校驗簽名，詳細方法請參考安全規範-簽名算法 |
二、狀態碼規範
204 No Content
如果更新成功，且客戶端屬性保持最新，服務器必須返回204 No Content狀態碼。適用於PUT請求，以及僅調整links，不涉及其它屬性的POST, DELETE請求
200 OK
如果服務器接受更新，但是在請求指定內容之外做了資源修改，必須響應200 OK以及更新的資源實例，像是向此URL發出GET請求.
201 Created
如果服務器需要創建一些資源, 比如創建用戶, 創建用戶數據, 創建資源, 默認API的create方法返回這個狀態碼.
301 Moved Permanently
被請求的資源已永久移動到新位置, 適用於資源link的變更,服務器做出兼容API.
303 See Other
對應當前請求的響應可以在另一個 URI 上被找到，客戶端應該使用 GET 方法進行請求, 適用於舊API往新API的兼容.
400 Bad Request
請求體包含語法錯誤, 出現本錯誤服務端應該向客戶端發送出錯描述
適用於:
- 發送了無法轉化的請求體
401 Unauthorized
需要驗證用戶身份，如果服務器就算是身份驗證後也不允許客戶訪問資源，應該響應 403 Forbidden, 適用於未登錄檢查
403 Forbidden
服務器拒絕執行
適用於:
- 服務到期（比如付費的增值服務等）
- 因爲某些原因不允許訪問（比如被 ban ）
- 權限不夠，403 狀態碼
404 Not Found
找不到目標資源
適用於:
- 需要修改的資源不存在
405 Method Not Allowed
不允許執行目標方法，響應中應該帶有 Allow 頭，內容爲對該資源有效的 HTTP 方法
406 Not Acceptable
服務器不支持客戶端請求的內容格式（比如客戶端請求 JSON 格式的數據，但服務器只能提供 XML 格式的數據）
409 Conflict
請求操作和資源的當前狀態存在衝突
410 Gone
被請求的資源已被刪除
412 Precondition Failed
服務器在驗證在請求的頭字段中給出先決條件時，沒能滿足其中的一個或多個。主要使用場景在於實現併發控制
413 Request Entity Too Large
POST 或者 PUT 請求的消息實體過大
415 Unsupported Media Type
服務器不支持請求中提交的數據的格式
422 Unprocessable Entity
請求格式正確，但是由於含有語義錯誤，無法響應
適用於:
- 發送了非法的資源
428 Precondition Required
要求先決條件，如果想要請求能成功必須滿足一些預設的條件 適用於:
- 缺少了必要的頭信息
500 Internal Server Error
服務器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。
501 Not Implemented
服務器不支持當前請求所需要的某個功能。 501 與 405 的區別是：405 是表示服務端不允許客戶端這麼做，501 是表示客戶端或許可以這麼做，但服務端還沒有實現這個功能
502 Bad Gateway
作爲網關或者代理工作的服務器嘗試執行請求時，從上游服務器接收到無效的響應。
503 Service Unavailable
由於臨時的服務器維護或者過載，服務器當前無法處理請求。這個狀況是臨時的，並且將在一段時間以後恢復。如果能夠預計延遲時間，那麼響應中可以包含一個 Retry-After 頭用以標明這個延遲時間（內容可以爲數字，單位爲秒；或者是一個 HTTP 協議指定的時間格式）。如果沒有給出這個 Retry-After 信息，那麼客戶端應當以處理 500 響應的方式處理它。
適用於: 服務器維護中
三、安全規範
1.簽名算法
簽名生成的通用步驟如下：
第一步，設所有發送或者接收到的數據爲集合M，將集合M內非空參數值的參數按照參數名ASCII碼從小到大排序（字典序），使用URL鍵值對的格式（即key1=value1&key2=value2…）拼接成字符串stringA。 特別注意以下重要規則：
- 參數名ASCII碼從小到大排序（字典序）；
- 如果參數的值爲空不參與簽名；
- 參數名區分大小寫；
- 驗證調用返回或主動通知簽名時，傳送的sign參數不參與簽名，將生成的簽名與該sign值作校驗。
- 接口可能增加字段，驗證簽名時必須支持增加的擴展字段
第二步，在stringA最後拼接上key得到stringSignTemp字符串，並對stringSignTemp進行MD5運算，再將得到的字符串所有字符轉換爲大寫，得到sign值signValue。
舉例，假設傳送的參數如下：
<?php
$id = '380840976';
$author_id = '1000000';
$body = 'test';
$date = gmdate('D, d M Y H:i:s \G\M\T');
第一步：對參數按照key=value的格式，並按照參數名ASCII字典序排序如下：
<?php
$stringA= "id=".$id."&author_id=".$author_id."&body=".$body."&date=".$date;
第二步：拼接API密鑰並進行簽名：
<?php
$stringSignTemp=$stringA."&key=302006259b3c09247ec02edaf64f6a5f";
$sign=strtoupper(MD5($stringSignTemp));
最終得到最終發送的數據
2.發送請求
將上一步生成的簽名，放到 HTTP 消息頭中。如果沒有簽名或者簽名錯誤，則會導致接口調用失敗，服務端會返回 HTTP 狀態碼 401
格式如下：
<?php
$headers = [
"Date: ".$date, // header 中使用的時間必須和生成簽名的時間$date相同
"Authorization: Blogchina $appid:".$sign,//$appid 爲開發者申請的appid
];
$body = [
'id'=>$id,
'author_id'=>$author_id,
'body'=>$body,
'date'=>$date,
];
$response = Unirest\Request::post("http://api.blogchina.com/", $headers, $body);
$response->raw_body;
3.回調API安全
在普通的網絡環境下，HTTP請求存在DNS劫持、運營商插入廣告、數據被竊取，正常數據被修改等安全風險。用戶回調接口使用HTTPS協議可以保證數據傳輸的安全性。所以建議用戶回調採用HTTPS協議。