如何正确合理的设计一个接口项目

时间:2013-10-08 11:43 来源:wangpeng047 作者:wangpeng047

  首先,我这里说明接口,不是代码里的接口,而是接口项目,如果想错了就不用往下看了。

  在手机广泛流行的今天,手机应用也随之越来越多,而且成长的速度也非常快。手机应用软件开发实现方式同普通PC软件一样,也分为BS和CS方式。而采用CS方式,在服务器端大多采用接口的形式提供数据交互(主流数据交互方式有:Json、WebService等),今天要说的就是如何设计接口。

  接口作为连通客户端与数据库进行数据流通的桥梁,起着举足轻重的作用,直接影响着程序的效率性、稳定性、可靠性以及数据的正确性、完整性。客户端注重的是界面美观,操作方便顺畅,是用户最直接的感受体验,而接口则是所有数据的提供者,是用户深层的内涵体验。

  因次,设计接口在一个项目中,是非常重要的。那么我就目前的经验总结下如何合理设计接口。

  一、 设计原理

  1. 深入了解需求

  除了设计数据库的人最了解需求外,其次就是设计接口的人了,甚至有时接口开发人员还要参与到数据库设计中。从“客户端-接口-数据库”的层次上看,接口明显扮演着承上启下的角色,一方面要明白接口要什么数据,另一方面要考虑如何从数据库获取、组织数据。所以如果不了解需求,你就无法正确抽象对象来组织数据给客户端,也无法验证数据库的数据结构能否满足需求。数据库设计者要了解需求中的数据结构,而接口则更多的要了解需求中的逻辑结构以及由此衍生出的逻辑数据结构。

  2. 了解数据库结构

  既然接口要明白如何从数据库获取、组织数据,就当然要了解数据库结构啦。

  3. 了解客户端原型

  了解原型,其实更多是为了帮助你设计接口时需要提供的数据和结构。但有时当你设计时并没有原型,所以此条并不是必须要求的。但假如设计完接口后原型出来了,我们也可以拿原型还验证接口设计是否正确、合理。

  二、设计原则

  1. 充分理由

  不是随便一个功能就要有个接口,也不是随便一个需求就要加个接口。每新建一个接口,就要有充分的理由和考虑,即这个接口的存在是十分有意义额价值的,无意义的接口不仅增加了维护的难度,更重要是对于程序的可控性的大大降低,接口也会十分臃肿。因此我放在了第一条。

  2. 职责明确

  一个接口只负责一个业务功能,它与设计模式里的职责单一原则类似但却不同,因为一个业务功能里可能会包含多个操作,比如查询会员,可能除了查询会员表外还要获取该会员的其他必要信息,但不要在查询会员的同时还有修改权限等类似的其他业务功能,应该分成两个接口还做。

  3. 高内聚低耦合

  一个接口要包含完整的业务功能,而不同接口之间的业务关联要尽可能的小。还是查询会员的例子,有时查询会员的同时,可能该会员的相关信息要随之发生变化(如状态),如果这时一条完整的业务流水线,那么就应该在一个接口里完成,而不应再单独设立接口去操作完成。就是说一个接口不应该随着另一个变化而变化或以某几个接口为前提而存在。

  4. 分析角度明确

  设计接口分析的角度要统一明确。否则会造成接口结构的混乱。例如,不要一会以角色的角度设计,一会儿就要以功能的角度设计。

  5. 入参格式统一

  所有接口的参数格式要求及风格要统一,不要一个接口参数是逗号分隔,另一个就是数组;不要一个接口日期参数是x年x月x日风格,另一个就是x-x-x。

  6. 状态及消息

  提供必要的接口调用状态信息。调用是否成功?如果失败,那么失败的原因是什么。这些必要的信息必须要告诉给客户端。

  7. 控制数据量

  一个接口返回不应该包含过多的数据量,过多的数据量不仅处理复杂,对数据传输的压力也非常大,会导致客户端反应缓慢。过多的数据量很多时候都是接口划分不明确。

  8. 禁止随意拓展参数

  与第1条类似,只不过是针对参数而言了。日后拓展接口可能是难以避免的,但是不要随意就加参数,加参数一定是必要且有意义的,需求改变前首先应考虑现有接口内部维护是否能满足需求,而不要通过加个参数来方便自己实现需求的难度,因为参数的更变会直接导致客户端调用的变化,容易产生版本兼容性问题。

  三、设计方法

  1. 抽象业务

  相比抽象对象而言,抽象业务更宏观,我觉得相对也容易一些,但抽象尺度往往不太好把握。

  2. 数据格式

  接口定义的数据格式必须都经过充分考虑,否则会出现数据转换失败或超出长度等错误。如果无法确定,直接设置成字符串是最合适的。

  3. 有意义的命名

  无论是接口还是参数,名称都应该是有意义的,让人能看明白的。

  总之,接口设计是一个细致的工作,设计时也会有很多矛盾,但个人倾向于粗粒度设计方向(即内聚性更高一些),这样不仅给客户端浏览接口方便明确,维护也轻松些,这么做的缺点就是某一接口扩展时不是很灵活,但可以通过重新定义一个接口来弥补,但正如上所说,新增接口还是要三思而后行的。以上很多虽然都是理论性讲解,但牢牢记住这些,并结合实际工作,就会慢慢深刻的体会到其中的含义。即理论指导实践,实践来验证理论。

时间: 2024-10-09 13:07:57

如何正确合理的设计一个接口项目的相关文章

使用CXF+spring+restful创建一个web的接口项目

此文为http://blog.csdn.net/zxnlmj/article/details/28880303的下文,在其基础上添加restful功能 1.添加restful的所需jar包 jsr311-api-1.0.jar CXF与JAX-RS版本对应问题,参考自:http://bioubiou.iteye.com/blog/1866871 CXF支持REST风格的Web服务:JAX-RS2.0(JSR-339)和JAX-RS1.1(JSR-311)的Java API. CXF2.7.0支持

使用CXF+spring创建一个web的接口项目

一.web project整合spring 1.1.打开Myeclipse,建立web project(eclipse为dynamic web project),使用J2EE5.0. 1.2.添加Srping的基本jar包(无需事务等) org.springframework.beans-3.1.1.RELEASE.jar commons-logging.jar org.springframework.aop-3.1.1.RELEASE.jar org.springframework.asm-3

Autofac在项目中应用的体会,一个接口多个实现的情况

在本人接触的项目中Autofac应用的比较多一些,我理解的他的工作原理就是  注册类并映射到接口,通过注入后返回相应实例化的类! 下面说说我在项目中的实际应用 先来简单介绍下Autofac的使用 1.通过Nuget或代码安装autofac 安装autofac :install-package autofac 安装对mvc4的支持:install -package autofac.mvc4(本人项目为mvc4) 2.新建相应的类及接口,并在autofac中进行映射 2.1.新建接口 INewsHe

如何设计一个良好的接口

在设计接口时,有很多因素要考虑,如接口的业务定位,接口的安全性,接口的可扩展性.接口的稳定性.接口的跨域性.接口的协议规则.接口的路径规则.接口单一原则. 接口过滤和接口组合等诸多因素,本篇文章将简要分析这些因素. 一 规范性建议 1.职责原则 在设计接口时,必须明确接口的职责,即接口类型,接口应解决什么业务问题等 2.单一性原则 在明确接口职责的条件下,尽量做到接口单一,即一个接口只做一件事,而非两件以上.很多非资深接口设计者,在设计接口时, 总认为接口所做的事越多,越牛叉,这是非常严重的错误

如何设计一个安全的对外接口

作者:ksfzhaohui my.oschina.net/OutOfMemory/blog/3131916 前言 最近有个项目需要对外提供一个接口,提供公网域名进行访问,而且接口和交易订单有关,所以安全性很重要:这里整理了一下常用的一些安全措施以及具体如何去实现. 安全措施 个人觉得安全措施大体来看主要在两个方面,一方面就是如何保证数据在传输过程中的安全性,另一个方面是数据已经到达服务器端,服务器端如何识别数据,如何不被攻击:下面具体看看都有哪些安全措施. 1.数据加密 我们知道数据在传输过程中

如何设计一个优雅的RESTFUL的接口

一 .引入 设计接口是我们开发人员的日常操作.当我们把接口交给前端人员时,是否有种拔剑出鞘的错觉.毕竟交付接口,我们的开发工作就阶段性完成了.不过,如果我们没有一个接口设计规范的时候,结果会怎样呢?我们来张图感受一下. 二.REST 2000年,一个年轻小伙子(Roy Thomas Fielding)在他的博士论文提出了 REST.REST 是一种万维网软件架构风格.为什么说是风格不是标准呢?个人理解可能说标准就有点过分了.小伙子做不到.随后这种风格被推广开来,漂洋过海,被大众熟知.在 REST

设计一个 iOS 控件

代码的等级:可编译.可运行.可测试.可读.可维护.可复用 前言 一个控件从外在特征来说,主要是封装这几点: 交互方式 显示样式 数据使用 对外在特征的封装,能让我们在多种环境下达到 PM 对产品的要求,并且提到代码复用率,使维护工作保持在一个相对较小的范围内:而一个好的控件除了有对外一致的体验之外,还有其内在特征: 灵活性 低耦合 易拓展 易维护 通常特征之间需要做一些取舍,比如灵活性与耦合度,有时候接口越多越能适应各种环境,但是接口越少对外产生的依赖就越少,维护起来也更容易.通常一些前期看起来

六大设计原则--接口隔离原则【 Interface Segregation Principle】

声明:本文内容是从网络书籍整理而来,并非原创. 定义 第一种定义: Clients should not be forced to depend upon interfaces that they don't use. 客户端不应该依赖它不需用的接口. 第二种定义: The dependency of one class to another one should depend on the smallest possible interface. 类间的依赖关系应该建立在最小的接口上. 两种定

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

App与服务器的通信接口如何设计得好,需要考虑的地方挺多的,在此根据我的一些经验做一些总结分享,旨在抛砖引玉. 安全机制的设计 现在,大部分App的接口都采用RESTful架构,RESTFul最重要的一个设计原则就是,客户端与服务器的交互在请求之间是无状态的,也就是说,当涉及到用户状态时,每次请求都要带上身份验证信息.实现上,大部分都采用token的认证方式,一般流程是: 用户用密码登录成功后,服务器返回token给客户端: 客户端将token保存在本地,发起后续的相关请求时,将token发回给