Openapi 接口設計思路

時間 2019-11-17

標籤 openapi 接口設計思路简体版

原文原文鏈接

Open API即開放API,也稱開放平臺。所謂的開放API（OpenAPI）是服務型網站常見的一種應用，網站的服務商將本身的網站服務封裝成一系列API（Application Programming Interface，應用編程接口）開放出去，供第三方開發者使用，這種行爲就叫作開放網站的API，所開放的API就被稱做OpenAPI（開放API）。

之前的軟件開發都是針對特定的用戶或羣體進行設計,但用戶的需求是千差萬別的,衆口難調就是這個道理。隨着軟件開發的發展,人們的關注點和設計模式也在悄悄發生着變化,我與其針對特定客戶進行開發,不如站在大衆的角度進行設計,把本身從甲方乙方的魔咒中解禁出來,本身成爲甲方。也就是說我之前開發的軟件只給你用,你還不滿意,如今我只提供核心業務,你本身來對接,你想設計成什麼樣子就設計成什麼樣子。因而 Opean Api 應運而生！！淘寶、阿里、騰訊都是這麼幹的,人家是大公司,規則的制定者,人家怎麼規定接口,你就得怎麼對接！！有一個網站叫聚合數據專門提供一些免費的和收費的優秀 API,有興趣的能夠上去註冊玩玩。數據庫

關於如何開發這樣的一套接口,刨除實際的業務邏輯不說,咱們來看看怎麼設計?下面是我在設計的時候遇到問題的思考,可能不全面僅供參考!編程

先來看看有那幾點須要考量?我也是憑經驗和 Google。設計模式

簽名鑑權（我須要知道請求個人是誰,有沒有訪問這個接口的權限）
流量控制（我不可能讓你隨隨便便就無節制的訪問我,我要能隨時關停你）
請求轉發（請求過來的 url,須要找到真正的業務處理邏輯,api最好只負責接口的規範,不負責業務的實現）
日誌處理（你能夠保持沉默,但你說的每一句話都會成爲呈堂供證）
異常處理（即便老子內部出了問題,你也不會看到個人異常堆棧信息,我會告訴你我病了,請稍後再試）
參數規範（順我者倡,逆我者亡）
多機部署（我有九條命）
異步回調（別想阻塞我,但我能夠玩死你）
錯誤信息（你要認識到本身錯誤）

作API,尤爲是 Open API 最重要的就是安全、安全、安全,試想一下,你的接口我能夠隨隨便便就猜對帳號密碼,隨隨便便就能夠DDOS 你,你都沒有辦法保證用戶信息的安全,誰還敢用你。其實你是在作一件反黑客的設計,呵呵,是否是高大尚了不少。api

Client:你怎麼知道一個請求是我而不是別人呢?安全

API:你若是對接我,我給你起一個全世界惟一名字就吧,你請求的時候就告訴我你叫 xxx,賦值到請求中的app_key中就行,至於這個字段叫app_key仍是叫 UserName仍是叫 client_id,這個看你心情了。因而就有了接口的第一個功能,給客戶起一個惟一名字。服務器

Client:若是別人也知道了這個用戶名,冒充我怎麼辦?網絡

API:我還會給你一個配套的密碼,密碼只有你我知道,你請求的時候,把密碼帶過來,我先驗證密碼,密碼經過了我才容許訪問。這樣就沒人能冒充的了你了吧。你密碼丟了,那就是你本身的事情了。app

Client:如今 HTTP 都是明文通訊,我每次訪問都帶上個人帳號密碼,那不等於廣而告之天下嗎?就像拿着一袋子錢在路上邊走邊喊「快來搶我呀！快來搶我呀！」，一個小小的嗅探器就能把用戶的密碼拿到手，若是用戶習慣在全部地方用一個密碼，那麼你闖大禍了，黑客經過撞庫的方法能把用戶的全部信息一鍋端。異步

API:那就就用你的帳號密碼先到我這兒換取一個口令吧,咱們叫 token,這樣攜帶口令且口令正確的咱們就認,沒有攜帶口令或口令不正確的咱們幾次絕,這樣你就不用帶着密碼滿世界跑了。網站

Client:可是那若是 Token 被截獲了呢？黑客重放怎麼辦！！

API:這個口令是有一個過時時間的好比10分鐘、一個小時、一天、3個月等等,大家也能夠作到單點登陸,我這邊也能夠有效的控制外人的入侵,同時避免了重複信息的反覆查詢數據庫和對比等操做,絕對能夠提升響應速度,校驗 token 的有效性花費的時間絕對比查數據庫要來的快啊。咱們在服務器端接口被調用時就能夠對發起請求的ip地址、user-agent之類的信息做比對，以防止僞造。再而後，若是token的有效期設得小，過一下子它就過時了，除非黑客能夠持續截獲你的token，不然他只能乾瞪眼。