正文 

当前位置： 首页 > java > java示例

app架构设计经验谈:接口的设计

zzfx      2022-02-09     120

关键词：

http://blog.csdn.net/utilc/article/details/50495830

App与服务器的通信接口如何设计得好，需要考虑的地方挺多的，在此根据我的一些经验做一些总结分享，旨在抛砖引玉。

安全机制的设计

现在，大部分App的接口都采用RESTful架构，RESTFul最重要的一个设计原则就是，客户端与服务器的交互在请求之间是无状态的，也就是说，当涉及到用户状态时，每次请求都要带上身份验证信息。实现上，大部分都采用token的认证方式，一般流程是：

  1. 用户用密码登录成功后，服务器返回token给客户端；
  2. 客户端将token保存在本地，发起后续的相关请求时，将token发回给服务器；
  3. 服务器检查token的有效性，有效则返回数据，若无效，分两种情况：
    • token错误，这时需要用户重新登录，获取正确的token
    • token过期，这时客户端需要再发起一次认证请求，获取新的token

然而，此种验证方式存在一个安全性问题：当登录接口被劫持时，黑客就获取到了用户密码和token，后续则可以对该用户做任何事情了。用户只有修改密码才能夺回控制权。

如何优化呢？第一种解决方案是采用HTTPS。HTTPS在HTTP的基础上添加了SSL安全协议，自动对数据进行了压缩加密，在一定程序可以防止监听、防止劫持、防止重发，安全性可以提高很多。不过，SSL也不是绝对安全的，也存在被劫持的可能。另外，服务器对HTTPS的配置相对有点复杂，还需要到CA申请证书，而且一般还是收费的。而且，HTTPS效率也比较低。一般，只有安全要求比较高的系统才会采用HTTPS，比如银行。而大部分对安全要求没那么高的App还是采用HTTP的方式。

我们目前的做法是给每个接口都添加签名。给客户端分配一个密钥，每次请求接口时，将密钥和所有参数组合成源串，根据签名算法生成签名值，发送请求时将签名一起发送给服务器验证。类似的实现可参考OAuth1.0的签名算法。这样，黑客不知道密钥，不知道签名算法，就算拦截到登录接口，后续请求也无法成功操作。不过，因为签名算法比较麻烦，而且容易出错，只适合对内的接口。如果你们的接口属于开放的API，则不太适合这种签名认证的方式了，建议还是使用OAuth2.0的认证机制。

我们也给每个端分配一个appKey，比如Android、iOS、微信三端，每个端分别分配一个appKey和一个密钥。没有传appKey的请求将报错，传错了appKey的请求也将报错。这样，安全性方面又加多了一层防御，同时也方便对不同端做一些不同的处理策略。

另外，现在越来越多App取消了密码登录，而采用手机号+短信验证码的登录方式，我在当前的项目中也采用了这种登录方式。这种登录方式有几种好处：

  1. 不需要注册，不需要修改密码，也不需要因为忘记密码而重置密码的操作了；
  2. 用户不再需要记住密码了，也不怕密码泄露的问题了；
  3. 相对于密码登录其安全性明显提高了。

接口数据的设计

接口的数据一般都采用JSON格式进行传输，不过，需要注意的是，JSON的值只有六种数据类型：

  • Number：整数或浮点数
  • String：字符串
  • Boolean：true 或 false
  • Array：数组包含着方括号[]中
  • Object：对象包含在大括号{}中
  • Null：空类型

所以，传输的数据类型不能超过这六种数据类型。以前，我们曾经试过传输Date类型，它会转为类似于"2016年1月7日 09时17分42秒 GMT+08:00"这样的字符串，这在转换时会产生问题，不同的解析库解析方式可能不同，有的可能会转乱，有的可能直接异常了。要避免出错，必须做特殊处理，自己手动去做解析。为了根除这种问题，最好的解决方案是用毫秒数表示日期。

另外，以前的项目中还出现过字符串的"true"和"false"，或者字符串的数字，甚至还出现过字符串的"null"，导致解析错误，尤其是"null"，导致App奔溃，后来查了好久才查出来是该问题导致的。这都是因为服务端对数据没处理好，导致有些数据转为了字符串。所以，在客户端，也不能完全信任服务端传回的数据都是对的，需要对所有异常情况都做相应处理。

服务器返回的数据结构，一般为：

{
    code：0
    message: "success"
    data: { key1: value1, key2: value2, ... }
}
  • code: 状态码，0表示成功，非0表示各种不同的错误
  • message: 描述信息，成功时为"success"，错误时则是错误信息
  • data: 成功时返回的数据，类型为对象或数据

不同错误需要定义不同的状态码，属于客户端的错误和服务端的错误也要区分，比如1XX表示客户端的错误，2XX表示服务端的错误。这里举几个例子：

  • 0：成功
  • 100：请求错误
  • 101：缺少appKey
  • 102：缺少签名
  • 103：缺少参数
  • 200：服务器出错
  • 201：服务不可用
  • 202：服务器正在重启

错误信息一般有两种用途：一是客户端开发人员调试时看具体是什么错误；二是作为App错误提示直接展示给用户看。主要还是作为App错误提示，直接展示给用户看的。所以，大部分都是简短的提示信息。

data字段只在请求成功时才会有数据返回的。数据类型限定为对象或数组，当请求需要的数据为单个对象时则传回对象，当请求需要的数据是列表时，则为某个对象的数组。这里需要注意的就是，不要将data传入字符串或数字，即使请求需要的数据只有一个，比如token，那返回的data应该为：

// 正确
data: { token: 123456 }

// 错误
data: 123456

接口版本的设计

接口不可能一成不变，在不停迭代中，总会发生变化。接口的变化一般会有几种：

  • 数据的变化，比如增加了旧版本不支持的数据类型
  • 参数的变化，比如新增了参数
  • 接口的废弃，不再使用该接口了

为了适应这些变化，必须得做接口版本的设计。实现上，一般有两种做法：

  1. 每个接口有各自的版本，一般为接口添加个version的参数。
  2. 整个接口系统有统一的版本，一般在URL中添加版本号，比如http://api.domain.com/v2。

大部分情况下会采用第一种方式，当某一个接口有变动时，在这个接口上叠加版本号，并兼容旧版本。App的新版本开发传参时则将传入新版本的version。

如果整个接口系统的根基都发生变动的话，比如微博API，从OAuth1.0升级到OAuth2.0，整个API都进行了升级。

有时候，一个接口的变动还会影响到其他接口，但做的时候不一定能发现。因此，最好还要有一套完善的测试机制保证每次接口变更都能测试到所有相关层面。

androidapp的设计架构：mvc,mvp,mvvm与架构经验谈

AndroidApp的设计架构由David发表在天码营和MVC框架模式一样，Model模型处理数据代码不变在Android的App开发中，很多人经常会头疼于App的架构如何设计：我的App需要应用这些设计架构吗？MVC,MVP等架构讲的是什么？... 查看详情

寻找网站架构师！

寻找网站架构师要求:1，有网站程序开发经验和网站升级和维护，负责与平台相关团队的技术协调，指导其他工程师的设计开发工作；可以带领技术团队等技术管理工作；..2，按照产品设计要求，确定前后端及相关业务逻辑开发... 查看详情

ios之深入解析app的架构设计

一、概述①应用架构App架构是软件设计的一个分支，它关心的是如何设计一个App的结构。具体来说，它关注于两个方面：如何将App分解为不同的接口和概念层次部件，以及这些部件之间和自身的不同操作中所使用... 查看详情

api接口设计之tokentimestampsign具体架构与实现（app/小程序，传输安全）(代码片段)

Java生鲜电商平台-API接口设计之token、timestamp、sign具体设计与实现说明：在实际的业务中，难免会跟第三方系统进行数据的交互与传递，那么如何保证数据在传输过程中的安全呢（防窃取）？除了https的协... 查看详情

hybridapp架构设计思路

原文：HybridAPP架构设计思路关于Hybrid模式开发app的好处，网络上已有很多文章阐述了，这里不展开。本文将从以下几个方面阐述Hybridapp架构设计的一些经验和思考。通讯作为一种跨语言开发模式，通讯层是Hybrid架构首先应该考虑... 查看详情

架构设计-日志管理接口设计

在后端代码中，日志无处不在，自己设计自己的一套日志管理代码，提供一套好用的日志接口将大大方便代码的开发。其中在日志管理代码的编写中，主要有以下难点： 1.数目不确定的入参函数编写2.日志权限控制3.日志输出... 查看详情

前后端分离微服务架构如何设计

参考技术A前端前端开发人员专注业务的页面呈现，非常注重用户体验度，也是与各种角色打交道最多的。比如：一般前端工作包括六个部分：后端如果前后端职责划分很清楚的话，后端更多开发工作在于业务接口设计、业务逻... 查看详情

saas系统架构设计经验总结

...毕竟SaaS相对传统软件的优势非常明显。最近一年，有幸架构一个CrmSaaS系统，上线了几个月来，各方面都比满意。整个系统创建过程，踩了很多坑，收获也比较多。总结一下SaaS系统架构一些特点：1.分层设计SaaS系统分层大概是：... 查看详情

app后台架构设计方案设计思想与最佳实践

...做好一个App后台也是需要长期锤炼的。本篇文章从App后台架构的角度介绍。好了，下面进入正题：说起架构，我们先看一下何 查看详情

社交app的架构设计（技术篇)

  查看详情

社交app的架构设计（技术篇)

  查看详情

推荐的fpga设计经验时钟和寄存器控制架构特性使用

UseClockandRegister-ControlArchitecturalFeaturesFPGAsprovidedevice-wideclocksandregistercontrolsignalsthatcanimproveperformance.UseGlobalClockNetworkResourcesAlteraFPGAsprovidedevice-wideglobalclockro 查看详情

[转]soa架构设计经验分享—架构职责数据一致性

阅读目录：1.背景介绍2.SOA的架构层次2.1.应用服务（原子服务）2.2.组合服务2.3.业务服务（编排服务）3.SOA化的重构3.1.保留服务空间，为了将来服务的组合4.运用DDD+GRASP进行分析和设计（防止主观的判断导致错误的假设）5.SOA分布... 查看详情

架构设计概念

什么是架构设计？　　架构定义大的系统结构。是对需求的转化，上接业务，下接技术决策。架构设计包括静态架构设计和动态架构设计。静态架构设计：完成系统功能性需求，系统的整体结构动态架构设计：通用问题的解决方... 查看详情

java生鲜电商平台-云平台架构设计与服务治理平台架构设计(小程序/app)

Java生鲜电商平台-云平台架构设计与服务治理平台架构设计(小程序/APP)说明：Java生鲜电商平台-云平台架构设计与服务治理平台架构设计，本文只是抛砖引玉，希望对大家有所帮助.　　  云平台是个非常宽泛的领域，本节... 查看详情

非小型电子商务系统设计经验分享

...口进行查看具体字段。商品模块设计商品模块是支撑整个架构的核心，如果这块没设计好，那么所有后期的复杂 查看详情

游戏开发经验谈：对战类全球服游戏的设计与实现

上篇文章《游戏开发经验谈（一）：游戏架构里隐藏的五个坑及其应对方案》，我们主要讲解了游戏架构设计当中隐藏的一些坑及其应对方案，错过的小伙伴可以点击链接回溯之前的内容。本期内容，将会重点介绍对战类全球服... 查看详情

接口”安全机制”的设计

...+私钥：实现方式参考现在，大部分App的接口都采用RESTful架构，RESTFul最重要的一个设计原则就是，客户端与服务器的交互在请求之间是无状态的，也就是说，当涉及到用户状态时，每次请求都要带上身份验证信息。实现上，大部... 查看详情