2. 程式人生 > >http api設計規範

http api設計規範

阿新 • • 發佈：2019-01-18
CREATE TABLE `user_extra_relation` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主鍵', `user_id` bigint(20) DEFAULT NULL COMMENT 'user表中的id', `come_from` varchar(64) NOT NULL DEFAULT '' COMMENT '專案來源，例如APP要做一個母親節的活動,或者520活動，from=母親節活動,from=520活動，表明我做活動的一個轉化率,這個也必須有一個對照表, `device_id` varchar(64) NOT NULL DEFAULT '' COMMENT '
第一次產生使用者註冊的裝置id', `channel_code` varchar(32) NOT NULL DEFAULT 'self' COMMENT '渠道標識，self：自有渠道，其他外部渠道也可以註冊使用者,非必傳，預設 self', `platform_id` tinyint(3) unsigned NOT NULL DEFAULT '0' COMMENT '平臺ID，platformId 對照表,例如 1:web，2:iOS，3:Android，4:miniApp', `app_name` varchar(32) NOT NULL DEFAULT '' COMMENT '
appName 應用名稱, `token` varchar(64) NOT NULL DEFAULT '' COMMENT '使用者token', `timestamp` varchar(64) NOT NULL DEFAULT '' COMMENT '傳送請求時間戳', `channel` varchar(32) NOT NULL DEFAULT '' COMMENT '渠道來源,從哪個渠道上面下載的包（iOS就只有一個App Store，Android有小米，應用寶，豌豆莢等國內的渠道),這個也必須有一個對照表https://lexiangla.com/docs/27c78dba373e11e8892b5254004fae61'
, `push_id` varchar(64) NOT NULL DEFAULT '' COMMENT '假如產品或者運營需要我們給部分使用者推送訊息，可以根據其他公共引數把使用者分群，然後拿到pushid給他push訊息。', `init_stamp` varchar(64) NOT NULL DEFAULT '' COMMENT '首次安裝包時間戳', `device` varchar(64) NOT NULL DEFAULT '' COMMENT '裝置名', `system_version` varchar(32) NOT NULL DEFAULT '' COMMENT '系統版本', `app_version` varchar(32) NOT NULL DEFAULT '' COMMENT '我們自己APP的版本號', `extra` varchar(128) NOT NULL DEFAULT '' COMMENT '額外引數，後續做ABTesting等場景的時候會用到，也可以做一些額外的業務需求欄位，視各業務而定', `is_delete` tinyint(3) unsigned NOT NULL DEFAULT '0' COMMENT '是否刪除 0-未刪除、1-刪除', `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '建立時間', `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改時間', PRIMARY KEY (`id`), UNIQUE KEY `uk_user_id` (`user_id`) ) ENGINE=InnoDB COMMENT='使用者附加資訊表，表明使用者來源等，第一次產生userId時插入資訊到此表'

相關推薦

http api設計規範

CREATE TABLE `user_extra_relation` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主鍵', `user_id` bigint(20) DEFAULT NULL COMMENT 'user表中

API設計規範 ----Restful

creat cif created 排序 href use 服務 如果 pat 　　 Restful API設計指南 接下來我將介紹RESTful API的設計細節，探討如何設計一套合理、好用的API 一、協議 API與用戶的通信協議，總是使用HTTPs協議。

Python Restful API設計規範

探討 資源 表現層 gin htm 異步任務 sci 在服務器 type Python 之路，Restful API設計規範 理解RESTful架構 Restful API設計指南 理解RESTful架構 越來越多的人開始意識到，網站即軟件

RESTful API設計規範收集

版本控制 執行 tap cep 冪等性 解耦 sdn hyperlink radi 說明：其實沒有絕對的規範，達到90%即可。 理解RESTful架構：http://www.ruanyifeng.com/blog/2011/09/restful.html RESTful

Restful API設計規範

理解RESTful架構 Restful API設計指南     理解RESTful架構 越來越多的人開始意識到，網站即軟體，而且是一種新型的軟體。 這種"網際網路軟體"採用客戶端/伺服器模式，建立在分散式體系上，通過網際網路通訊，具有高延時（high latency）、高併發等

iOS 官方 Swift API 設計規範

核心原則 最重要的目標：每個元素都能夠準確清晰的表達出它的含義。做出 API 設計、聲明後要檢查在上下文中是否足夠清晰明白。 清晰比簡潔重要。雖然 swift 程式碼可以被寫得很簡短，但是讓程式碼儘量少不是 swift 的目標。簡潔的程式碼來源於安全、強大的

【RESTful】RESTful API 設計規範

概念 本質：一種軟體架構風格 核心：面向資源設計的API 解決問題： 降低開發的複雜性 提高系統的可伸縮性 例如：設計一套API，為多個終端服務。 設計概念和準則 網路上的所有事物都可以被抽象為資源 每一個資源都有唯一的資源標識，對資源的操作不會改變這些標

Restful HTTP API 設計分解

摘要 什麼是 RESTful RESTful 是一種軟體設計風格，或者直接理解為API介面編寫的規範。 RESTful特點 安全可靠，高效，易擴充套件 簡單明瞭，可讀性強，沒有歧義 API風格統一，呼叫規則，傳入引數和返回資料有統一的標準 RESTfu

Restful API設計規範學習筆記

1 api專有域名/或在專案中建立API專用目錄 2 URL中加入版本號 v1,v2(專案小可以不加) 3 資源名用名詞     eg：http://api.douban.com/v2/movie/ 名詞：movie，user... 4 記錄很多時，URL加引數進行

api設計規範

前言 說到restful，其實我們並不完全遵循restful規範。我們會參考restful的設計理念，並且結合我們自己的一些實踐來對web api進行設計。 我們一起來看看RESTFul API有哪些特點： 基於“資源”，資料也好、服務也好，在RESTF

理解 RESTful API 設計規範

RESTful是目前最流行的API設計規範，它是用於Web資料介面的設計。從字面可以看出，他是Rest式的介面，所以我們先了解下什麼是Rest。 REST與技術無關，它代表的是一種軟體架構風格，REST它是 Representational State Transfer的簡稱，中文的含義是: "表徵狀態轉移

Restful API 的設計規範

1. URI URI 表示資源，資源一般對應伺服器端領域模型中的實體類。URI規範 不用大寫; 用中槓-而不用下槓_; 引數列表要encode; URI中的名詞表示資源集合，使用複數形式; 資源集合與單個資源 資源集合： /

Http API閘道器服務模組設計方案（微服務）

Http  API閘道器服務模組設計方案1. 概述                           閘道器作為服務生產者和服務消費者之間的介面，一方面通過“服務路由”為服務消費找到所需服務的具體位置並呼叫；另一方面為後臺伺服器提供負載均衡、安全、流量控制、身份認證等相關功

知乎日報 API 分析(如何規範api設計)

宣告 以下所有 API 均由 知乎（Zhihu.Inc） 提供，本人（Xiao Liang）採取非正常手段獲取。獲取與共享之行為或有侵犯知乎權益的嫌疑。若被告知需停止共享與使用，本人會及時刪除此頁面與整個專案。 請您暸解相關情況，並遵守知乎協議。 API 說明 知乎日報的訊息以 JSON 格式輸出

【RESTful】RESTful API 介面設計規範 | 示例

概念 本質：一種軟體架構風格 核心：面向資源設計的API 解決問題： 降低開發的複雜性 提高系統的可伸縮性 例如：設計一套API，為多個終端服務。 設計概念和準則 網路上的所有事物都可以被抽象為資源 每一個資源都有唯一的資源標識，

HTTP API響應資料規範

出處: 概述 本文件為本人對長期開發API介面所整理的經驗總結，如有不完善或不合理的地方，望各位多提意見。 文件目的為規範伺服器端API介面，便於伺服器端與客戶端程式碼重用。伺服器端和客戶端可根據實際所定義規範編寫序列化和反序列化工具，以便減少一些開發時間。 本

API 介面設計規範

概述 這篇文章分享 API 介面設計規範，目的是提供給研發人員做參考。 規範是死的，人是活的，希望自己定的規範，不要被打臉。 路由命名規範 動作 字首 備註 獲取 get get{XXX} 獲取 get get{XXX}List 新增 add add{XXX} 修改 update u

RESTful API 設計指南

head 簡單 option eat set 取出 tro 其他 first 　　網絡應用程序，分為前端和後端兩個部分。當前的發展趨勢，就是前端設備層出不窮(手機、平板、桌面電腦、其他專用設備……)。 　　因此，必須有一種統一的機制，方便不同的前端設備與後端進行通信。這

Restful API設計

rfc mage erro art 狀態 存在 asc tar 區分 理解RESTful架構 越來越多的人開始意識到，網站即軟件，而且是一種新型的軟件。 這種"互聯網軟件"采用客戶端/服務器模式，建立在分布式體系上，通過互聯網通信，具有高延時（high latency

JavaScript 的 API 設計原則

rst 執行 creat 錯誤 htm ora 大小 閱讀 fontsize 前言 本篇博文來自一次公司內部的前端分享，從多個方面討論了在設計接口時的原則，總共包含了七個大塊。系鹵煮自己總結的一些經驗教訓。同時也參考了一些文章，地址會在後面貼出來。很難做到詳盡充實，如果