接口设计相关知识
-
转账接口设计在一个项目中,一般都会支付相关的业务,而涉及到支付必定会有转账的操作,转账这一步想起来算是比较关键的部分,这个接口的设计能力,也大致体现出一个人的水平。 昨天碰到了一个题目: 尝试用java编写一个转账接口,传入主要业务参数包括转出账号,转入账号,转账金额,完成转出和转入账号的资金处理,该服务要确保在资金处理时转出账户的余额不会透支,金额计算准确。 设计 首先一般在系统中的参数不会有这么少,一般情况下请求参数还会有一些公共的信息,比如请求来源(请求ip与系统)、请
-
API 接口设计中Token设计讨论在实际的网站设计中我们经常会遇到用户数据的验证和加密的问题,如果实现单点,如果保证数据准确,如何放着重放,如何防止CSRF等等。其中,在所有的服务设计中,都不可避免的涉及到Token的设计。目前,基于Token的生成方,我们把Token生成分为两种类型。1、基于用户/网站,可见的加密请求方式2、基于服务器间通讯的不可见加密请求方式(API Token)其中,基于非服务器端的请求,我们要根据实际的应用场景进行一定的自定义加工。在本次讨论中我们把非服务的请求分为了两部分。需要登录的登录态Token不需要登录的临时态Token两种请求中:1、非登录态请求要求用户访问页面时会随机生成唯一且有时效性的token,该token在每次请求时都是不同。改方法用于当不需要登录界面的请求多且无法使用静态页面的时候使用,Token会在一定的时间内失效,以此来防止被机器爬取不需登录的界面2、登录状态中,token会保存一定的时间,页面中的token会作为用户身份识别,同时登录态的Token需要利用session和页面信息来防止被利
-
支付中心接口设计之参数命名目前,java版支付中心处在研发阶段。下午,特有钻研精神的云龙同学饶有兴趣的问我“战哥,你觉得表字段用哪种命名方式比较好呢?”所用的db是mysql,他是想征求一下我的看法,是用驼峰式命名还是小写加下划线方式。我直截了当地说用驼峰式。为什么? 我认为,像java语言或.net语言,实体类的属性一般是遵从驼峰式命名的(稍有不同的是java一般首字母小写,而.net是首字母大写)。我们的程序里的数据访问层一般均采用ORM框架。如果表字段是小写字母+下划线,那么,相应的POJO/POCO实体类的属性也会是小写字母+下划线,这样,违背了驼峰式命名规范,有违代码的整洁度。接着,如我所期,云龙问“那你支付中心对外的api接口参数为什么用小写+下划线的方式呢?”我答道,对外提供的接口,如果用驼峰式。 首先,我们用word编写接口说明文档时,在参数表格列里输入参数名后,如果按tab键,则word默认首字母是大写的。而如果恰好我们的首字母是小写时,如果我们在编写时忽略了这个细节,这就会给对接者带来疑惑(产品设计上有一条重要的
-
Spring+SpringMVC+MyBatis+easyUI整合进阶篇(二)接口设计及Java后端实现前言 原计划这部分代码的更新也是上传到ssm-demo仓库中,因为如下原因并没有这么做: 有些使用了该项目的朋友建议重新创建一个仓库,因为原来仓库中的项目太多,结构多少有些乱糟糟的。 而且这次的代码改动较大,与原来的目录结构及代码风格相比都有很大的差别。 同时也考虑到不同的人所处的学习阶段不同,担心有人不习惯也不适应这种风格及后面的更新,有的朋友甚至可能是初学者,更适合学习ssm-demo这个基础项目。 基于以上几点,最终并没有选择把几个项目都放在一个代码仓库中,而是另外
接口设计相关课程
接口设计相关教程
- 3. 接口设计 软件的接口是指软件模块对外提供的一组函数或者方法,目的是让别的模块访问本模块的功能,以达到组件复用的目的。根据模块逻辑复杂度的不同,接口由分为:系统接口、子系统接口、模块接口、子模块接口、类接口。关于模块、子模块、类的应用都非常灵活,我们这里认为类就是最小的模块。本小节所说的接口是指 Java 接口。我们抽象了三个 Java 接口:Listener、IOHandler、IOAdapter,还有一个功能类 Poller。现在对每个接口中的方法加以说明:Poller类名接口名描述Pollerregister将 IOHandler 实例添加到 Pollerstart启动一个 Poller 实例close停止一个 Poller 实例pollPoller 进入事件循环IOHandler类名接口名描述IOHandlerhandle_read是一个回调方法,当 Poller 监听到某个 IOHandler 注册的读事件触发时,调用 handle_readhandle_write是一个回调方法,当 Poller 监听到某个 IOHandler 注册的写事件触发时,调用 handle_writehandle_accept是一个回调方法,当 Poller 监听到某个 IOHandler 注册的accept事件触发时,调用 handle_accepthandle_connected是一个回调方法,当 Poller 监听到某个 IOHandler 注册的connected事件触发时,调用 handle_connectedgetSocketChannel用于获取 IOHandler 对应的 SocketChannel 对象IOHandler 是一个抽象接口,TcpHandler 需要实现此接口,当然你也可以实现其他协议,只需要扩展 IOHandler 的接口即可。IOAdapter类名接口名描述IOAdapteronAccept当 IOHandler 收到一个新的 TCP 连接时,在 handle_read 中回调此方法onConnected当 io_hanIOHandlerdler 完成异步连接时,在 handle_connected 中回调此方法onReadIOHandler 会在 handle_read 中回调此方法onWriteIOHandler 会在 handle_write 中回调此方法onCloseIOHandler 收到连接被关闭时,回调此方法setSocketHandler向 IOAdapter 设置一个 IOHandler 对象应用层需要实现 IOAdapter 的接口,并且要覆盖接口中的方法,完成数据收发。Listener类名接口名描述Listenerprocess处理异步事件
- 3. Django 接口规范 对于 Django 的 URL 接口规范,遵循如下几点规则:开发之前,先要详细设计项目的 API 接口,包括输入参数以及响应数据的格式,最好能形成相关的接口文档;URL 接口要按照应用划分,每个 App 目录里面要有自己的 urls.py 文件。里面是本应用中的所有 url 和 视图的映射关系。总的 url 入口在 settings.py 文件中配置,默认是和 settings.py 文件同目录下的 urls.py;对于 URL 接口本身,倾向于使用 Restful 风格的 API 接口设计,比如接口:/manage/user:对应的 GET、POST、PUT 和 Delete 请求,我们往往会对应着用户模型 user 的增删改查操作这样的规范只是一种广泛使用的 API 接口设计风格,并不是必须的。因此在 Django 中的 各种 View 类来辅助我们设计这样的 API 接口。在项目中实现 Django 的 Web API 接口时,往往是使用 DFR (Django Rest Framework)来辅助构建项目的 API 接口。DRF 在 Django 的基础上迅速实现 API ,并且自身还带有 Web 的测试页面,可以方便的测试自己的 API 接口;最后就是关于公司内部接口设计人的喜好了,比如有人喜欢讲第一版本和第二版本接口设计用这样的 URL区分:https://example.com/api/v1/book/1 -> v1 版本接口https://example.com/api/v2/book/1 -> v2 版本接口还有设计响应数据的格式,也要简单明了。比如可以简单使用如下的 JSON 数据表示响应结果:{ "code": 200, # 响应码 "content": [] or {} or "", # 返回数据内容,可以是[]、{} or str等 "err_msg": "" # 错误信息}
- 5. 接口索引计数器与接口索引集合 父类索引后边紧跟的是接口索引计数器,接口索引计数器后边紧跟的是接口索引集合。类似于常量池计数器和常量池的关系,接口索引计数器记录的是接口索引集合中接口索引的数量。Tips:对于常量池计数器和常量池,一个是无符号数类型,一个是表类型。相比而言,接口索引计数器和接口索引集合皆为无符号数类型,这里学习者可以进行对比记忆。我们继续来看下两者的定义以及无符号数类型的结构示意图。定义:接口索引计数器:代表了接口索引集合中接口的数量;接口索引集合:按照当前类 implements(或当前接口extends)的接口的顺序,从左到右依次排列在接口索引集合中,此部分集合称为接口索引集合。无符号数结构示意图:接口索引计数器和接口索引集合均为无符号数类型结构,结构示意图如下图所示。从图中可以看出,接口索引计数器占用了 2 个字节,为 u2 大小,接口索引集合中的每一个接口元素占用了 2 个字节大小,也为 u2 大小。Tips:接口索引集合后边紧跟的数据结构是什么?我们继续抛出问题,后续章节会有问题的解答,让我们带着问题继续探究 Class 文件结构。
- 3. 设计原则 那么使用设计模式能为软件开发带来什么好处呢?这要从设计模式的设计原则说起,一般来说有6大原则,如下:单一职责原则顾名思义,一个类最好只有一个职责。这样的好处是引起类发生变化的原因会很少。我们开发新需求的时候,就会很少去修改这个类。而且职责越单一也越容易被复用。开闭原则软件应该对扩展开放,对修改关闭。通俗易懂的说,就是你的软件不能因为加功能,就不断地修改已有的类。而是应该通过增加类,以插拔的方式来实现。举个例子,Macbook的变压器插头是可以替换的,如果说某一天插口的标准换了,那么苹果只需要开发一个新的插头就好了,而不需要重新开发整个变压器。开闭原则确保了代码最大程度的可复用性。并且确保了成熟代码的稳定性。里氏代换原则子类型可以替换掉自己的父类。这意味着我们编写的软件,所有使用父类的地方,都可以替换为子类对象,而程序的行为不会发生改变。通过里氏代换原则,我们可以实现开闭原则,通过增加子类实现新的功能,而不是不断地修改父类。在需要的地方则用子类代替父类。如何实现里氏代换原则呢?首先子类不能重写父类的非抽象方法,一旦重写了非抽象方法,就会改变父类的行为。但是子类可以增加自己的方法和属性,以此达到扩展的目的。依赖倒转原则简单说就是应该依赖接口,而不是实现。也就是我们常说的面向接口编程。这样类和类之间就不会直接依赖,从而能够实现开闭原则。类依赖接口,当需要扩展的时候我们可以替换实现。迪米特法则也称为最少知道原则。如果两个类没有必要直接通信,那么两个类就没有必要相互作用。可以通过第三方来间接调用。类之间的耦合度越弱,越容易被复用。在弱耦合的关系中,一个类的修改,造成的影响会很小。所以我们在做设计的时候需要考虑哪些应该对外暴露,哪些应该封装起来。不同功能模块间的调用,应该由更为高层的类来实现,从而屏蔽掉底层的实现。接口隔离原则接口隔离原则指导你如何设计接口。不要让接口变得臃肿,而是应该把接口按照行为不同细拆。比如你要生产一把可以拼刺刀的步枪,那它应该实现两个接口,刀的接口和枪的接口。而不是使用一个接口覆盖所有刀和枪的所有行为。这样不同的接口可以组合使用。而且如果你只需要刀或者枪的行为,可以单独实现需要的接口, 不需要实现一个大而全的接口,从而去实现很多用不到的方法。如果你的代码满足以上设计原则,就会更为健壮、灵活和优雅。那么如何做到上面这些原则呢?很简单,学习好设计模式,灵活运用设计模式解决你的问题。
- 6. 接口和抽象类的区别 接口的方法默认是 public ,所有方法在接口中不能有实现(Java 8 开始接口方法可以有默认实现),而抽象类可以有非抽象的方法;接口中除了 static 、final 变量,不能有其他变量,而抽象类可以;一个类可以实现多个接口,但只能实现一个抽象类。接口自己本身可以通过 extends 关键字扩展多个接口;接口方法默认修饰符是 public ,抽象方法可以有 public 、protected 和 default 这些修饰符(抽象方法就是为了被重写所以不能使用 private 关键字修饰!);从设计层面来说,抽象是对类的抽象,是一种模板设计,而接口是对行为的抽象,是一种行为的规范。
- RESTFUL 开发设计规范 上节我们刚了解完 URI ,知道它是一种资源标识,而 URL 是 schema = Http 的子标识,本节要讲的 Restful 从小的讲是对 URL 格式提出了限制,对接口设计规范的倡导,大的说它是一种通信架构的指导。
接口设计相关搜索
-
j2ee
j2ee是什么
jar格式
java
java api
java applet
java c
java jdk
java list
java map
java script
java se
java socket
java swing
java switch
java web
java xml
java 程序设计
java 多线程
java 环境变量