首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏陌无崖知识分享

    HTTP接口设计

    PUT,PATCH,OPTIONS方法 默认情况下请求实体会被视作标准 json 字符串进行处理,当然,依旧推荐设置头信息的 Content-Type 为 application/json 在一些特殊接口中 参数的介绍的修正 JSON Web Token,一种 Token 的生成标准 Json Web Tokens: Introduction Json Web Tokens: Examples 数据缓存 大部分接口应该在响应头中携带 Content-Location 跨域 CORS 接口支持“跨域资源共享”(Cross Origin Resource Sharing, CORS),这里和这里和这份中文资料有一些指导性的资料。 Access-Control-Max-Age: 86400 Access-Control-Allow-Credentials: true JSON-P 如果在任何 GET 请求中带有参数 callback ,且值为非空字符串,那么接口将返回如下格式的数据

    2.6K20发布于 2020-07-27
  • 来自专栏斑斓

    面向接口设计与角色接口

    标签 | 软件设计 字数 | 1876字 阅读 | 5分钟 问题:在做项目的时候,是不是所有包含非静态方法的类,都要写一个接口?是因为这样的目的是为了解耦,然后通过DI注入实现吗? 此外,如果你的接口永远都只有一个实现类,并没有任何可能的需求变化,那么还有必要解耦吗? 所以说,不能死板的将类的方法提取接口,然后美其名曰为面向接口设计。 我们不能误解“面向接口设计”原则,该原则所指的“接口”并非Java语言中的interface类型,而是指面向调用者对外暴露的接口,代表一种交互与协作,是对信息的隐藏和封装,而不是具体的interface 即使是普通的java方法仍然满足隐藏细节的原则,如果是public的,就可以认为该方法是“面向接口设计”中的接口,也就是说:不要针对实现细节编程,而是针对接口编程。 如果你先定义了一个类叫EmailService,然后因为你需要定义接口对其抽象,然后就简单地将这个类的所有公有方法都提取到抽象的接口中,这样设计接口,被Martin Fowler称为Header Interface

    97310发布于 2018-07-27
  • 来自专栏全栈程序员必看

    怎样设计接口

    怎样设计接口? 众所周知,接口是提供给其它模块或者系统使用的一种约定或者规范。因此接口必需要保 证足够的稳定性和易用性。这是设计接口的基本要求。 这是一种糟糕的接口设计。既不便于使用又不便于编译器优化(待确认)。 3.怎样设计接口? 採用OOD思想,即面向对象的思想,提供类接口或者COM接口。 对于C函数接口怎样设计呢? 事实上和C++接口设计原则一样,也採用面向对象的思想,仅仅是 将类设计成结构,公共的成员函数变为全局的函数,私有的成员函数变为static函数就可以。 函数接口的第一參数就相当于C++中的this指针就可以。 4.接口设计的其它要求 * 规范性:主要是接口设计的代码规范,这是最主要的要求。

    1.2K30编辑于 2022-07-13
  • 来自专栏子勰随笔

    SDK设计心得之接口设计

    由于SDK的特殊性,所以对于SDK的开发来说,一开始对于SDK的一些通用的整体的元素的设计至关重要。因为SDK(尤其很多平台SDK,使用的应用成百上千)一个及其细微的调整都会影响很多开发者的版本周期。 因此前期的设计显得尤为重要。关于这部分内容,我会分两篇来介绍,这篇重点介绍具体接口设计。另一篇SDK设计心得之架构和资源将重点介绍SDK的架构和一些资源的使用方式。 关于接口设计 设计原则 接口名称、参数名称要足够清晰 一个牛逼的接口名称可以替代无数的注释 一个接口只做一件事 一个接口只做一件事。 我们有个功能有两个接口:一个是需要传参数,另一个不需要传参,两者的逻辑完全是独立的。本来是根据第一个原则设计了两个信、达也算雅的接口来实现。 其实这里游戏反映接入成本高,我们应该是去分析什么原因引起的接口成本身高,能不能优化。不能直观的认为一个功能要两个接口接口太多了接入成本就高,就要删接口

    6.7K90发布于 2018-05-22
  • 来自专栏跟Qt君学编程

    设计模式-流畅接口

    何为流畅接口?先上代码String("1")("2")("3")("4")("5")。流畅接口从字面上看是用起来很顺手,究竟是有多顺手,又应用在哪里呢?相信你看完本文多少会有些答案了。 我们再看下QString的 arg()接口的使用。 并可以通过它来体现流畅接口。 ; 明确确定设置参数后需要调用build接口生效,这就意味着可以提醒接口调用者生效了那些参数。 让接口调用者用来顺手(流畅)。

    95320发布于 2019-08-20
  • 设计API接口原则】

    如果当初设计API时只图自己省事,定了个死板的字段名、严格的校验规则,或者不预留扩展字段,现在被100个团队调用后,任何一个微小的改动都可能引发雪崩式的兼容性问题——那时候不只是别人骂我,我自己都想穿越回去抽自己 比如: 接受参数时,对非关键字段做宽松解析(比如容错大小写、允许空值、支持多种格式的时间字符串); 返回结果里,保留未知字段而不是直接抛错,让调用方可以渐进式升级; 版本控制清晰,老接口至少留足半年的缓冲期 毕竟,一个接口的终点,可能是上百个系统的起点。 这句非常经典!这是API设计的黄金法则。当一个接口从内部自用扩展到外部生态时,设计复杂度会指数级上升。 // 设计一个用户信息查询API interface UserQueryRequest { userId? 预留字段、宽松校验、错误容忍,这些看似"偷懒"的设计,实际上是在为整个生态的稳定性买单。

    25410编辑于 2025-12-18
  • 来自专栏测试开发社区

    接口用例设计

    背景说明 一个系统可为其他系统提供能力或者直接为UI层提供数据,在设计系统测试方案时应考虑上游调用的各种场景,不仅考虑顺利且正向思维操作的场景,还应逆向的场景。 换句话来说,使用契约式设计的方式,运行前条件必须满足,参数不正确不可运行;运行中内部状态必须不变;运行后结果必须保持一致。 在设计接口用例设计时,除实现功能外,应关注:幂等性、空校验、流程节点限制、异常校验。 ? 01 幂等性 何为幂等性? 幂等为一数学概念,指使用相同参数重复执行,能获取相同结果。 对非空参数依次传空,观察接口调用情况。 当然,首先需明白业务逻辑,从而进行用例设计。尤其对于参数复杂的接口,当某一条调用规则下 某些非空参数就需要作为必传了。 明确系统的状态流转,一个系统设计初期就需明确功能及状态流转,会依据产品对系统的定义及依赖的下游或三方产品的功能。 测试正常流程节点。按照正向流程依次调用,观察调用结果及生成状态。

    2.3K31发布于 2020-04-26
  • 来自专栏编程园地

    API接口TOKEN设计

    API(Application Programming Interface)即应用程序接口。你可以认为 API 是一个软件组件或是一个 Web 服务与外界进行的交互的接口。 ; 针对以上特点,移动端与服务端的通信就需要两种不同的TOKEN,一种针对接口的api_token,一种针对用户的user_token; 一.api_token 它的职责是保持接口访问的隐蔽性和有效性 加密密钥'为私有的加密密钥,手机端需要在服务端注册一个“接口使用者”账号后,系统会分配一个账号及密码,数据表设计参考如下: 字段名及字段类型 client_id varchar(20) 客户端ID client_secret = md5('用户的uid' + 'Unix时间戳') = etye0fgkgk4ca2ttdsl0ae9a5dd77471fgf 服务端用数据表维护user_token的状态,表设计如下: 字段名及字段类型如下 ; 接口用例如下:添加测试接口 URL: http://www.api.com/demo/index/add-demo?

    2.1K30编辑于 2022-03-02
  • 来自专栏大前端(横向跨端 & 纵向全栈)

    RESTful 接口设计指南

    因此,必须有一种统一的机制,方便不同的前端设备与后端进行通信,这导致 API 构架的流 行,甚至出现"API First"的设计思想,RESTful API 是目前比较成熟的一套互联网应用程序的 API 设计理论。

    86210发布于 2020-11-26
  • 来自专栏Hercules

    RESTful接口设计风格

    遵循RESTful风格,可以使开发的接口通用性更好,统一规范,减少沟通、学习和开发的成本。

    39010编辑于 2023-08-23
  • 来自专栏PHP在线

    API接口TOKEN设计

    API(Application Programming Interface)即应用程序接口。你可以认为 API 是一个软件组件或是一个 Web 服务与外界进行的交互的接口。 ; 针对以上特点,移动端与服务端的通信就需要两种不同的TOKEN,一种针对接口的api_token,一种针对用户的user_token; 一.api_token 它的职责是保持接口访问的隐蔽性和有效性 加密密钥'为私有的加密密钥,手机端需要在服务端注册一个“接口使用者”账号后,系统会分配一个账号及密码,数据表设计参考如下: 字段名及字段类型 client_id varchar(20) 客户端ID client_secret = md5('用户的uid' + 'Unix时间戳') = etye0fgkgk4ca2ttdsl0ae9a5dd77471fgf 服务端用数据表维护user_token的状态,表设计如下: 字段名及字段类型如下 ; 接口用例如下:添加测试接口 URL: http://www.api.com/demo/index/add-demo?

    5.9K140发布于 2018-03-09
  • 来自专栏程序那些事儿

    如何设计api接口

    随着前后端的分离,api 接口变得越来越重要,作为前后端通信的接口,api 变得非常重要,而且它的设计也是非常难以掌握。不仅要考虑安全性,还要考虑可维护性,以及今后的升级等等。 如何才能设计出更好的 api 接口,我认为以下几点需要注意。 接口一致性 这里说的一致性指的是编码规范要统一,不能各个接口使用不一样的编码风格。 接口健康性检查 我们应该设计一个监控系统或者一个接口来实时监控我们的服务,如果接口出现了问题,我们应该能够第一时间发现,同样,对于每个接口的访问请求我们都要有日志记录的存储。 尽量采用restful风格 虽然restful风格被一些人质疑,但是目前来看,它还是最好的接口设计风格,通过采用restful风格,可以让接口语义更加明确 ,规范,优雅省去了大部分 无意义的沟通,通过使用不同的 提供完整详细的api文档 无论我们的接口设计的多么规范,多么易懂,我们都需要提供一份完整的api文档,同时我们还需要提供一些请求范例,这样用户在使用的时候才会更加清楚,也能避免一些错误的请求。

    1.2K50编辑于 2023-03-07
  • 来自专栏AI技术体系搭建过程

    0226 rest接口设计

    ** API设计原则 先给接口来个简单的定义:即协议,约定了请求和响应的参数和格式。 接口设计要求是: 1.简洁; 2.考虑到向后兼容; 业界有一些基本的原则: 1 restfull restfull是一种设计风格,一切接口皆是资源。 目前是设计的主流,思想也非常先进。 一般在接口设计的时候,可以带入透传参数,比如时区,位置(省市区),系统类型,系统版本,应用类型,应用版本等; 5 幂等 即接口的第一次请求的结果和后面N次的重试结果要不变,需要结合场景来保证。 API设计实践 接口框架选型 有了接口设计的原则,可以挑选一个可靠的接口框架来支持自己的工作, 一个好的接口框架应该有如下特点: 对访问控制的支持; 自动测试的支持; 请求响应格式和序列化的支持; 日志和日志过滤的支持 ** 小结 通过本篇文章你可以学到如下内容: [ ] 接口设计的原则 [ ] 接口设计框架选型要点 [ ] 接口设计过程中的设计实践问题 设计良好的接口,可以提高软件的复用性,提高团队的输出效率和质量。

    21500编辑于 2025-07-01
  • 来自专栏四火的唠叨

    关于接口设计,还有 Fluent Interface,这种有趣的接口设计风格

    这个故事是从下面这样一个对外暴露接口的调用开始的。 QueryUserEvent.SEX_MALE); …… List<User> userList = userService.query(event); 我想做的事情其实很简单,我想查询一个用户列表,可是接口参数的拼装让我感到头疼 sex : User.SEX_MALE }, UserService.QUERY_TYPE_NORMAL); 不过,他接着说,在 Java 里面好像还没有类似简洁的表示方法…… 万幸的是,有一种接口连续调用的风格 greaterThan(new User().setAge(18)).setSex(User.SEX_MALE).query(UserService.QUERY_TYPE_NORMAL); 我想,这样的设计如果在数学计算的时候 对于 Fluent Interface 而言,它的接口调用既改变了对象的状态,又返回了对象(this 或其他),并不属于上面的两种类型。

    52620编辑于 2022-07-15
  • 来自专栏白驹过隙

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

    在后端代码中,日志无处不在,设计一套自己的日志管理代码,给框架提供一套好用的日志接口将大大方便代码的开发。 接口设计: 1.提供三类日志打印形式:1)控制台打印信息,类似printf的接口封装             2)函数追踪接口,打印当前代码的文件名,函数名及行,以及一些设定的输出参数              提供打印级别控制,且打印内容输出到日志文件中 2.提供日志级别控制:1)在打印日志时提供当前日志级别,代码依据级别进行控制打印           2)日志打印级别控制暂时使用配置文件,后续可以通过通信接口进行实时修改

    80440发布于 2018-06-25
  • 来自专栏白驹过隙

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

    在后端代码中,日志无处不在,设计一套自己的日志管理代码,给框架提供一套好用的日志接口将大大方便代码的开发。 接口设计: 1.提供三类日志打印形式:1)控制台打印信息,类似printf的接口封装             2)函数追踪接口,打印当前代码的文件名,函数名及行,以及一些设定的输出参数              提供打印级别控制,且打印内容输出到日志文件中 2.提供日志级别控制:1)在打印日志时提供当前日志级别,代码依据级别进行控制打印           2)日志打印级别控制暂时使用配置文件,后续可以通过通信接口进行实时修改

    85080发布于 2018-05-18
  • 来自专栏IT当时语_青山师_JAVA技术栈

    设计模式】之接口设计分离原则

    接口分离设计原则 接口分离设计原则主要是为了解决接口臃肿的缺陷。 接口如果包含不是特定于它的方法就称为污染的或者臃肿的接口。 客户端不应该被强制依赖它们本不需要使用的接口。。 现在开发同事想编写一个 Print 类实现 IMachine 接口。 你注意到这个问题了吗?尽管你仅仅需要打印功能,但你却不得不去实现 IMachine 接口。 现在, IMachine 接口不再遵循接口分离原则了,开始变成了 “臃肿”的接口。 为了避免 IMachine 接口成为一个违背分离原则而成为臃肿的接口,我们可以将 IMachine 接口分散成多个特定的接口。 你可以使用 适配器模式 去分离接口接口分离原则使实现变得简单,方便调试和继续维护。 接口分离原则很容易理解,在理论上也是比较友好的,但是很难识别不同的接口,往往以接口的增殖而告终。

    21310编辑于 2023-05-05
  • 来自专栏java思维导图

    如何设计restful风格接口

    restful风格接口 URL定位资源,用HTTP动词(GET,POST,DELETE,DETC)描述操作。 REST描述的是在网络中client和server的一种交互形式;REST本身不实用,实用的是如何设计 RESTful API(REST风格的网络接口); 2. 比如:左边是错误的设计,而右边是正确的 GET /rest/api/getDogs --> GET /rest/api/dogs 获取所有小狗狗 GET /rest/api/addDogs --> POST

    1.6K20发布于 2018-07-26
  • 来自专栏OpenFPGA

    PHY_MDIO 接口设计

    PHY 内部寄存器的读写通过 MDIO 接口进行。 8.5.2.1 MDIO 接口 MDIO 接口由数据传输时钟 MDC 和双向数据信号 MDIO 组成,如下图所示 ? 图8‑33 MDIO接口 MDIO 为双向接口,在 PHY 芯片外部需要连接上拉电阻, 1 个 MDIO 接口可以同时连接多个 PHY 芯片。 图8‑37 0x19的寄存器 8.5.2.1 模块设计 (一)模块结构 MDIO接口模块结构如下图所示,由模块mdio_top及其子模块mdio_control组成。 ? 图8‑38 MDIO接口模块结构 (二)模块接口 (1)mdio_top模块 mdio_top模块各接口定义如下表所示。 表8‑10 mdio_top模块接口定义 接口名称 信号方向 接口说明 clk input 输入参考时钟 reset input 模块全局复位信号,高电平有效 mdio_en input MDIO接口使能信号

    5.8K42发布于 2020-06-30
  • 来自专栏测试开发技术

    RobotFrameWork接口设计规范

    那么接口在开始之前,你觉得需要有哪些规范呢?下面我就介绍一下以前我在公司开展接口项目时,制定的一些针对接口项目的约定规范。 )、H5_Mobile(H5页面调用的接口)、Mobile_Socket(前端调用socket协议的接口)。 3.2、接口命名规则 自动化脚本中接口命名通常可以按照接口部分url+接口方法类型组成,部分url是指非参数部分的最后两级路径。 所以最好的方式是在在设计之初的阶段就要考虑好用例的分类,而在RobotFramework中通过标签Tag的形式,很方便就可以将用例划分成不同归类。 接口定义方面需要有属于如个版本需求、用途。如用接口有修改需要增加修改原因和版本及其用途记录; c. 测试用例对业务用例需要注解其验证点,其它类型可自行要求。 d.

    1K10发布于 2020-01-17
领券