实用篇：接口开发的那些“软技能”

最新推荐文章于 2024-01-04 23:21:55 发布
最新推荐文章于 2024-01-04 23:21:55 发布
阅读量401 收藏
点赞数 1
分类专栏： java 文章标签： postman java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/SocaintC/article/details/127308971
版权

文章目录

经常在技术群里或者各种博客中看到大家在争执API测试工具应该用哪个，什么http client，postman，apifox，jmeter，那该如何选择适合自己的工具呢，如何才能提高生产力，更快的做完手上工作呢，其实，归根到底，没有最好，只有适合自己的才是最好的，在接口开发的不同阶段，选择适合自己的工具，来更快的实现目标就行。

CURD多年，前后台测试接口，跨团队测试接口，后台调用外部接口，经常性的会出现各种各样的扯皮现象，主要来来回回就是这几个：

  • 接口格式不对
  • 接口字段不对
  • 接口缺失字段
  • 接口不够规范
  • 接口不够稳定

那，该如何避免或者节省这之间的来来回回的开销呢？

设计

  1. 定规范

    1. 确定请求方式，常用的 GET POST，REST规范的GET/POST/DELETE/PUT，其他的OPTIONS/PATCH/COPY/HEAD/LINK/UNLINK/PURGE/LOCK/UNLOCK/PROPFIND/VIEW

    2. 定请求参数，是request param还是request body,request body类型是什么

    3. 接口是否需要安全校验，采用哪种校验方式

    4. 返回体结构，一般来说后端返回的数据，会基于标准的HTTP STATUS在额外封装一层，用于关联业务或者后台内部的处理逻辑。

      {
    "code":200,
    "msg":"请求成功",
    "data":{}
}

  2. 约定返回体结构的CODE标准，一般采用标准的http status(200/400/401/403/500常用，在实际开发过程中，部分开发人员会对部分http状态码做自定义定义，需在接口最开始，定好全局规范)

  3. 约定返回体结构的实际业务数据结构，一般来说，包括以下内容：

    类型
    字段名称
    是否必选
    类型
    中文含义

文档工具

本人经常用的接口文档工具是swagger和RAP2。但在实际工作中，碰到的部分同事，基于开发人员自己的习惯，总是想着现有代码，才有接口，这就陷入了一个误区。接口不是一个人的事情，往大了说，属于整个项目运转过程中的一个个生命线，往小了说，是接口开发方和接口使用方之间的"冲突博弈"过程。

所以，不管是用什么工具，提前定义好接口字段，然后双方进行各自调试，完成后，进行合并验证，是最高效的开发方式。

swagger

用于团队内部之间的对接开发，所见即所得，可提供实际数据的便捷查询。

RAP2

一般用于跨团队、跨部门的协同开发工作，提供mock，项目组前端同事可直接直接调用测试。

测试和监控

接口对接阶段是最容易发生扯皮的地方，因个人做的是政府相关项目，一般来说，开发环境的数据没法做到百分百模拟正式环境，和其他同事或者团队对接时候，经常性出现这种问题，开发调试阶段，接口不符合规范，好不容易接口调完了，拿到正式环境，数据一上来，发现对方提供的数据标准又有问题。

网络隔离，VPN速度慢，各种来回扯皮，让人烦不胜烦。

于是逐渐开始思考，能否利用自己手上已有的工具，尽量做到尽快定位问题，尽快排查问题呢？经过一段时间的探究，针对接口对接过程中的相关问题，研究出了以下方法论

外部保护->POSTMAN tests

1.添加环境变量

一般来说，环境变量包括IP、参数、token等，即分为两种，静态变量和动态变量，变量一般统一放在collection中的Variables中

image-20221013155643797

使用方法：{{variable_name}}

  • 静态变量

    静态变量一般就是接口的请求参数，可以直接通过双括号进行引入

    image-20221013155825529

  • 动态变量

    最常见的动态变量就是header中的各种校验参数，token最为常见，一般接口提供方会额外提供一个token请求接口，配合postman的Pre-request Scripts进行使用

    pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});
 
// 把responseBody转为json字符串
var data = JSON.parse(responseBody);
// 设置环境变量token，供后面的接口引用，位置就是上一步获取的位置
pm.environment.set("access_token", data.result.access_token);

    image-20221013160033227

2.设置测试方法
2.1 全局测试

对所有接口来说，共通就是返回体结构测试，即保证code正确、数据不为空

在collection中进行Tests添加

pm.test("HTTP请求 200", function () {
    pm.response.to.have.status(200);
});

var jsonData = pm.response.json();

pm.test("接口返回200", function () {
    pm.expect(jsonData.resultCode === 200).to.equal(true);
});

pm.test("接口返回数据不为空", function () {
    if(Array.isArray(jsonData.result)){
        pm.expect(jsonData.result.length > 0).to.equal(true);
    }else{
        pm.expect(jsonData.result !== null).to.equal(true);
    }
});
2.2 接口schema校验

  • json转json schema

    postman内置了Ajv JSON schema validator的校验方式，为了方便起见，我们需要把接口设计阶段定义的json转为json schema，然后通过 pm.response.to.have.jsonSchema进行校验

    • 如接口定义阶段，json模拟数据如下

      {
  "resultCode": 200,
  "resultMsg": "success",
  "result": {
    "basicData": {
      "shipCode": "与四山立百",
      "shipNo": "但命及风他",
      "shipRegNo": "最离矿则它设历",
      "shipFirstregNo": "光具样任般高时",
      "origShipRegNo": "构天当斯消然",
      "shipId": "她提圆性识",
      "origShipName": "根得取特水应干",
      "shipIdFlagCode": "了细十产",
      "shipInspectNo": "布人关油速热酸",
      "shipImo": "行家适青",
      "shipMmsi": "马铁至土治那",
      "shipCallsign": "所目入口安华日",
      "shipName": "向等代手研",
      "shipNameEn": "接上决压除",
      "origShipNameEn": "头接治",
      "shipRegionFlagCode": "机石家毛党布",
      "shipRouteCode": "更与林几器",
      "sailAreaCode": "根设眼实值还",
      "regportCode": "格重安程速",
      "origRegportName": "结中上时",
      "shipHullMaterialCode": "片流便包还众",
      "shipTypeCode": "备满发直安外能",
      "shipValue": "线革商再",
      "shipLength": 39657,
      "shipBreadth": 56071,
      "shipDepth": 98131,
      "shipGrosston": 93962,
      "shipNetton": 55891,
      "shipDwt": "斯取声对律公人",
      "shipEngineTypeCode": "然此已认",
      "shipEngineNum": 5815,
      "shipEnginePower": 20505,
      "shipPropellerTypeCode": "适较八自情放",
      "shipPropellerNum": 81206,
      "shipSlotNum": 63116,
      "shipParkNum": 23051,
      "shipPassengerNum": 91588,
      "shipSummerDraft": 1200,
      "shipWindLevel": "号话用",
      "shipMinFreeboard": 30004,
      "shipyard": "造口放将信下",
      "shipyardEn": "米选斯计改",
      "shipBuiltAddr": "转七入见发",
      "shipBuiltAddrEn": "空千律认商",
      "shipBuiltDate": "1983-05-14 10:06:54",
      "rebuiltShipyard": "点常主反行南类",
      "rebuiltShipyardEn": "也么以府有",
      "shipRebuiltAddr": "而是六水",
      "shipRebuiltAddrEn": "第自们断况",
      "icCardNo": "养听维点算办",
      "origDeletionDate": "1991-06-28 12:11:21",
      "shipRebuiltDate": "1985-04-07 13:17:08",
      "statusFlagCode": "矿行市正亲电",
      "shipIdSealFlagCode": "说亲变内",
      "mortgageFlagCode": "快需大半圆证",
      "bareboatFlagCode": "中位阶也论",
      "alterFlagCode": "江业查",
      "handoutCardFlagCode": "地王圆收究求",
      "financialLeaseFlagCode": "以主总上器东",
      "hibernateFlagCode": "意眼应处",
      "trialShipFlagCode": "选热上",
      "detainFlagCode": "型开所积",
      "permanentSealRemark": "光定部王手命动",
      "orgCode": "还行保在即",
      "shipRouteCodeCn": "列照她你",
      "shipReginFlagCodeCn": "河",
      "sailAreaCodeCn": "连速老江她",
      "shipTypeCodeCn": "内九量劳关",
      "shipRegionFlagCodeCn": "段示线所",
      "regportCodeCn": "化石值究",
      "shipEngineTypeCodeCn": "高构克他群",
      "shipPropellerTypeCodeCn": "个动所快理",
      "orgCodeCn": "商张说器形"
    }
  }
}

    • 通过在线工具进行转换，json schema转换

      {
  "type": "object",
  "required": [],
  "properties": {
    "resultCode": {
      "type": "number"
    },
    "resultMsg": {
      "type": "string"
    },
    "result": {
      "type": "object",
      "required": [],
      "properties": {
        "basicData": {
          "type": "object",
          "required": [],
          "properties": {
            "shipCode": {
              "type": "string"
            },
            "shipNo": {
              "type": "string"
            },
            "shipRegNo": {
              "type": "string"
            },
            "shipFirstregNo": {
              "type": "string"
            },
            "origShipRegNo": {
              "type": "string"
            },
            "shipId": {
              "type": "string"
            },
            "origShipName": {
              "type": "string"
            },
            "shipIdFlagCode": {
              "type": "string"
            },
            "shipInspectNo": {
              "type": "string"
            },
            "shipImo": {
              "type": "string"
            },
            "shipMmsi": {
              "type": "string"
            },
            "shipCallsign": {
              "type": "string"
            },
            "shipName": {
              "type": "string"
            },
            "shipNameEn": {
              "type": "string"
            },
            "origShipNameEn": {
              "type": "string"
            },
            "shipRegionFlagCode": {
              "type": "string"
            },
            "shipRouteCode": {
              "type": "string"
            },
            "sailAreaCode": {
              "type": "string"
            },
            "regportCode": {
              "type": "string"
            },
            "origRegportName": {
              "type": "string"
            },
            "shipHullMaterialCode": {
              "type": "string"
            },
            "shipTypeCode": {
              "type": "string"
            },
            "shipValue": {
              "type": "string"
            },
            "shipLength": {
              "type": "number"
            },
            "shipBreadth": {
              "type": "number"
            },
            "shipDepth": {
              "type": "number"
            },
            "shipGrosston": {
              "type": "number"
            },
            "shipNetton": {
              "type": "number"
            },
            "shipDwt": {
              "type": "string"
            },
            "shipEngineTypeCode": {
              "type": "string"
            },
            "shipEngineNum": {
              "type": "number"
            },
            "shipEnginePower": {
              "type": "number"
            },
            "shipPropellerTypeCode": {
              "type": "string"
            },
            "shipPropellerNum": {
              "type": "number"
            },
            "shipSlotNum": {
              "type": "number"
            },
            "shipParkNum": {
              "type": "number"
            },
            "shipPassengerNum": {
              "type": "number"
            },
            "shipSummerDraft": {
              "type": "number"
            },
            "shipWindLevel": {
              "type": "string"
            },
            "shipMinFreeboard": {
              "type": "number"
            },
            "shipyard": {
              "type": "string"
            },
            "shipyardEn": {
              "type": "string"
            },
            "shipBuiltAddr": {
              "type": "string"
            },
            "shipBuiltAddrEn": {
              "type": "string"
            },
            "shipBuiltDate": {
              "type": "string"
            },
            "rebuiltShipyard": {
              "type": "string"
            },
            "rebuiltShipyardEn": {
              "type": "string"
            },
            "shipRebuiltAddr": {
              "type": "string"
            },
            "shipRebuiltAddrEn": {
              "type": "string"
            },
            "icCardNo": {
              "type": "string"
            },
            "origDeletionDate": {
              "type": "string"
            },
            "shipRebuiltDate": {
              "type": "string"
            },
            "statusFlagCode": {
              "type": "string"
            },
            "shipIdSealFlagCode": {
              "type": "string"
            },
            "mortgageFlagCode": {
              "type": "string"
            },
            "bareboatFlagCode": {
              "type": "string"
            },
            "alterFlagCode": {
              "type": "string"
            },
            "handoutCardFlagCode": {
              "type": "string"
            },
            "financialLeaseFlagCode": {
              "type": "string"
            },
            "hibernateFlagCode": {
              "type": "string"
            },
            "trialShipFlagCode": {
              "type": "string"
            },
            "detainFlagCode": {
              "type": "string"
            },
            "permanentSealRemark": {
              "type": "string"
            },
            "orgCode": {
              "type": "string"
            },
            "shipRouteCodeCn": {
              "type": "string"
            },
            "shipReginFlagCodeCn": {
              "type": "string"
            },
            "sailAreaCodeCn": {
              "type": "string"
            },
            "shipTypeCodeCn": {
              "type": "string"
            },
            "shipRegionFlagCodeCn": {
              "type": "string"
            },
            "regportCodeCn": {
              "type": "string"
            },
            "shipEngineTypeCodeCn": {
              "type": "string"
            },
            "shipPropellerTypeCodeCn": {
              "type": "string"
            },
            "orgCodeCn": {
              "type": "string"
            }
          }
        }
      }
    }
  }
}

    • 根据接口实际情况，修改上述schema的具体定义

      如string字段可为空

      原始定义：

      "orgCodeCn": {
     "type": "string"
}

      修改后：

      "orgCodeCn": {
     "type": ["string","null"]
}

      如时间格式是YYYY-MM-DD

      原始定义：

      "origDeletionDate": {
    "type": "string"
}

      修改后：

      "origDeletionDate": {
    "type": "string",
    "pattern":"(([0-9]{3}[1-9]|[0-9]{2}[1-9][0-9]{1}|[0-9]{1}[1-9][0-9]{2}|[1-9][0-9]{3})-(((0[13578]|1[02])-(0[1-9]|[12][0-9]|3[01]))|((0[469]|11)-(0[1-9]|[12][0-9]|30))|(02-(0[1-9]|[1][0-9]|2[0-8]))))|((([0-9]{2})(0[48]|[2468][048]|[13579][26])|((0[48]|[2468][048]|[3579][26])00))-02-29)"
}

      具体schema的其他属性和相关说明，可参考 JSON Schema规范(中文版)

      注意：pattern用的是正则表达式，一些常用的正则在网上搜索一下，二次校验即可。没必要自己花大量精力造轮子。

3.批量运行

  • 先运行登录接口，更新token至全局变量

  • 泡杯热茶，运行整个collection

    image-20221013194222658

  • 查看运行结果，一眼便知道哪些接口有问题了

    image-20221013194400859

4.不同环境的处理办法

导出collection文件至内网实际环境，需要更换全局变量即可

内部保护->prometheus http埋点监控

在微服务中，网关服务可以完成对系统内接口的监控和流量检测，但很多时候，对复杂的业务系统来说，还需要对接外部的服务，硬编码rest请求处理。

如何保证系统可以持续观测外部接口的状态和处理时间呢，这里推荐使用springboot+prometheus的方式，对系统内的接口进行埋点监测，对异常的访问，配合alertmanager+webhook进行告警实时通知。

1.pom.xml 添加依赖
<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

<dependency>
	<groupId>io.micrometer</groupId>
	<artifactId>micrometer-registry-prometheus</artifactId>
	<version>1.8.5</version>
</dependency>
2.配置restTemplate

这里将系统内的restTemplate的默认HTTP请求先修改为OKHTTP

@Bean
public RestTemplate restTemplate(MeterRegistry registry) {

    // 先配置OKhttpClient，添加eventListener收集okhttpClient指标
    OkHttpClient client = new OkHttpClient
        .Builder()
            .sslSocketFactory(SSLSocketClient.getSSLSocketFactory(), SSLSocketClient.getX509TrustManager())
            .hostnameVerifier(SSLSocketClient.getHostnameVerifier())
            .eventListener(OkHttpMetricsEventListener
                           	.builder(registry, "okhttp.requests")
                				.uriMapper(req -> req.url().encodedPath())
                				.tags(Tags.of("okhttp", "performance"))
                   		   	.build())
        .build();
    
    OkHttp3ClientHttpRequestFactory factory = new OkHttp3ClientHttpRequestFactory(client);
    // 通过配置文件配置即可，注入代码省略
    factory.setConnectTimeout(connectTimeout);
    factory.setReadTimeout(readTimeout);
    factory.setWriteTimeout(writeTimeout);
    return new RestTemplate(factory);
}

@Bean
public OkHttpClient okHttpClient(MeterRegistry registry) {
    return new OkHttpClient.Builder()
            .eventListener(OkHttpMetricsEventListener.builder(registry, "okhttp.requests")
                    .tags(Tags.of("okhttp", "performance"))
                    .build())
            .build();
}
3.micrometer配置
@Configuration
public class MicroMeterConfig {
    @Bean
    public MeterRegistryCustomizer<MeterRegistry> meterRegistryCustomizer(@Value("${spring.application.name}") String applicationName) {

        return meterRegistry -> meterRegistry
                .config()
                 .commonTags(Collections.singletonList(Tag.of("application", applicationName)));
    }

    @Bean
    public TimedAspect timedAspect(MeterRegistry registry) {
        return new TimedAspect(registry);
    }
}
4.添加actuator暴露端点
management:
  endpoints:
    web:
      exposure:
        include: '*'

配置完成后，采用传统的方式进行使用即可

@Autowired
private RestTemplate restTemplate;
5.prometheus.yml添加配置
  - job_name: 'spring_grafana'
    scrape_interval: 5s
    scrape_timeout: 4s
    metrics_path: 'actuator/prometheus'
    static_configs:
      - targets: ['ip:port']
6.grafana添加dashboard

Spring Boot 2.1 System Monitor

最终效果

image-20221013201647147

链接汇总

  1. postman scripts
  2. JSON转SCHEMA在线工具
  3. RAP2接口文档管理
  4. grafana
  5. springboot使用Micrometer集成Prometheus监控
拾叁不是13
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
游戏开发需要具备哪些技术_app的开发需要哪些技术
weixin_39741459的博客
12-17 1934
1.前期的规划技术在开发一款app之前，需要制定出一个完整的方案计划，越详细越好，流程图要做的完整。只有前期准备的越充分，后续问题出现的才会越少。2.交互设计、UI设计的技术需要设计出基本且完善的原型图和app基础的交互设计效果图，并且页面要设计的简洁好看，还要考虑设计出来的app能不能适应不同的分辨率设备和不同手机系统。3.开发方式的技术要会不同的开发方式，比如原生开发、混合开发等。现在是混合开...
接口开发有哪些技术_脑机接口技术被评为医药卫生领域工程开发前沿技术TOP10...
weixin_32905035的博客
01-15 362
12月10日，中国工程院战略咨询中心、科睿唯安以及高等教育出版社在中国工程院联合发布《全球工程前沿2019》报告。报告围绕机械与运载工程、信息与电子工程、化工冶金与材料工程、能源与矿业工程、土木水利与建筑工程、环境与轻纺工程、农业、医药卫生、工程管理9个领域，遴选出年度全球工程研究前沿93项和全球工程开发前沿94项。2019年度全球工程前沿技术评选在专家为核心、数据为支撑的原则下，采用专...
5 天开发接口系统技术小结
qq__________qq的博客
01-12 199
在确定了接口系统的详细规划和整体功能以后，花费时间更多的其实是对技术细节的打磨。本主题借鉴我开发个人网站 魚立说 的经验，整理了在开发接口系统过程可能会遇到的各种技术要点。 本文来源：魚立说。本文链接：https://www.yulisay.com/d/cdmqv.html，支持微信浏览器打开。 更多精彩文章，请移步 魚立说个人网站 翻看。欢迎欣赏，吐槽不足之处。 涉及到的代码已经整理到 https://github.com/yulis-say/web-full-stack 中的 api-skills
面向接口/协议？看DuerOS的技能开发
我相信......
03-07 4038
一般地，开发一个对话系统或者机器人问答系统会涉及诸多领域的技术，除了硬件系统之外，还包括语言识别，自然语言处理/识别，知识图谱的搭建，自然语言生成及TTS播报等等，这对于企业及开发者个人而言，几乎是难以完成的任务。 有幸的是，对话式AI操作系统例如DuerOS的诞生，使我们可以直面业务逻辑，相对轻松地完成语音类服务的开发与实现。在过去的研发中，经常使用的往往是面向接口的设计方法，那么，面向对...
第四课：接口测试都要掌握哪些知识？
forevershow55的博客
09-16 263
接口测试都要掌握哪些知识？ ①了解系统及内部各个组件之间的业务逻辑交互； ②了解接口的I/O（input/output：输入输出）； ③了解协议的基本内容，包括：通信原理、三次握手、常用的协议类型、报文构成、数据传输方式、常见的状态码、URL构成等； ④常用的接口测试工具，比如：jmeter、loadrunner、postman、soapUI等； ⑤数据库基础操作命令（检查数据入库、提取测试数据等）； ⑥常见的字符类型，比如：char、varchar、text、int、float、datatime、stri
Xilinx FPGA开发全攻略(技巧篇)
07-13
在Xilinx FPGA开发过程中，掌握一系列实用技巧是至关重要的，这不仅能提高开发效率，还能确保设计的优化与高效运行。本篇文章将详细探讨Xilinx FPGA开发中的关键知识点，旨在为开发者提供全面的指导。 首先，我们...
FPGA开发全攻略基础和技巧篇
06-03
"FPGA开发全攻略基础和技巧篇"旨在为学习者提供一套全面的FPGA学习资源，涵盖基础知识与实用技巧，帮助开发者从零开始逐步掌握FPGA的设计与应用。 **基础篇** 1. **FPGA架构**：FPGA由可配置逻辑块（CLBs）、输入/...
FPGA设计-工程师设计宝典-开发人员手册-FPGA开发全攻略（上册）
08-21
总之，《FPGA开发全攻略》是一本全面、实用的FPGA学习资料，对于希望在FPGA设计领域提升技能的工程师来说，是不可多得的参考资料。通过阅读本书，读者不仅可以了解FPGA的基础知识，还能掌握实际设计中的关键技巧，为...
Linux私房菜基础篇
08-20
这本书是Linux初学者的福音，通过详细的学习和实践，读者可以建立起对Linux系统的深入理解和操作技能，为进一步的系统管理、编程开发或其他高级主题打下坚实的基础。《Linux私房菜基础篇》不仅提供了理论知识，还...
软键盘类编写如同输入法的软键盘
12-14
本篇将详细讲解如何编写一个类似于输入法的软键盘，以VC++（Visual C++）作为开发环境。 首先，我们来看`CIMESoftKbd.cpp`和`CIMESoftKbd.h`这两个文件。`CIMESoftKbd.cpp`是实现文件，通常包含了软键盘类的具体...
Apifox图文使用教程
最新发布
分享思想，留下痕迹。
01-04 4174
大家好，我是Leo哥🫣🫣🫣，本期专栏带来一些开发中一些好用的工具，以及教大家如何去使用，这一期带来的是当前最流行的APIApifox。好了，话不多说让我们开始吧😎😎😎。Apifox是集 API 文档、API 调试、API Mock、API 自动化测试多项实用功能为一体的 API 管理平台，定位为。旨在通过一套系统、一份数据，解决多个工具之间的数据同步问题。只需在 Apifox 中定义 API 文档；API 调试、API 数据 Mock、API 自动化测试等功能就可以直接使用，无需再次定义。
Apifox自动化测试添加步骤从接口导入引用参数不成功
Blog
05-23 855
背景：在接口管理单个接口调试的时候，设置了后置处理器，参数能正常引用；但是到了自动化测试的时候，参数引用失败。自动化测试的时候导入进来的接口，后置操作没有启用。但是自动化测试的时候却引用失败了。获取的接口能正常引用参数。新增的接口设置了后置操作。勾选启用后重新执行即可。
谈一谈API接口开发
Noah_ZX的博客
02-11 885
做过开发的程序猿，基本都写过接口，写接口不算难事，与接口交互的对象核对好接口的地址、请求参数和响应参数即可，我在作为面试官去面试开发人员的时候，有时候会问这个问题，但相当多的一部分人并没有深入的考虑过怎么写好一个接口，包括接口的可靠性、安全性和高并发等等。小编在项目开发过程中，与很多的企业对接过接口，包括一些小企业定制化的软件接口，也包括一些大厂形成规范的接口，比如支付宝、银联、微信，以及各大银行等等，相对来说，很多小厂的接口编写比较随意，而大厂对接口的定义就比较严谨，接下来我们就来分析一下。
是时候扔掉 Postman 了，Apifox 真香！
狐哥说技术
07-31 2341
是时候扔掉 Postman 了，Apifox 真香！ 作为开软件开发从业者，接口调试是必不可少的一项技能，在这方面 Postman 做的非常出色。但是在整个软件开发过程中，接口调试只是其中的一部分，还有很多事情 Postman 无法完成，或者无法高效完成，比如：接口文档定义、Mock 数据、接口自动化测试等等。Apifox 就是为了解决这个问题而生的。 接口管理现状 一、常用解决方案 使用 Swagger 管理接口文档 使用 Postman 调试接口 使用 RAP 等工具 Mock 数据 使用 JMe
一、接口开发-类别篇
qq_34609370的博客
07-09 1130
常见的类别如下： 1、java-sdk方式： 将对方提供的sdk包导入工程，根据开发文档，调用相应类方法即可。 2、rest接口： 客户端通过向服务器端发送 HTTP（s）请求，接收服务器的响应，完成一次 HTTP 交互。 3、rpc接口： 远程方法调用，就是像调用本地方法一样调用远程方法，通信协议大多采用二进制方式。 RPC可以通过HTTP来实现,也可以通过Socket自己实现一套协议来实现。现...
使用 Apifox 进行接口调试与集成测试的实践与经验总结。
gdjnrc_com的博客
05-31 4786
大家好，我是BOb 。我最近计划将我devtools中的所有接口维护在 Apifox 中。 Apifox，同 postman 一样，最基本的功能用来接口联调。 稍微高级点的用法可以使用 Apifox 生成各个语言发送请求的代码，针对 Image/File 进行请求，对 Request Body 与 Response Body 进行数据校验及测试。 「仅仅做到这些只是满足一个开发者的使用场景。而 Apifox 更高级的用法可以使整个团队进行受益，满足开发测试的各个阶段，对开发环境，测试环境，生产环境..
apifox接口测试工具
peace
11-27 4617
目录1 apifox介绍2 使用说明2.1 团队、人员管理2.2 对比2.3 重点内容2.3.1 关联2.3.2 变量2.3.3 断言2.3.4 环境变量 1 apifox介绍 apifox与postman、yapi功能类似，提供接口管理、用例管理功能。可以用来进行自动化测试。 2 使用说明 2.1 团队、人员管理 创建团队后，可以加入相关的开发人员、测试人员 理想应用场景： 开发维护接口、测试维护用例 2.2 对比 支持http和socket协议 对比yapi，对文件上传、文件下载的支持更友好 对比pos
接口神器：Apifox，究竟有多香！
一个摩羯座的程序猿
04-26 4178
一、介绍 Apifox 是接口管理、开发、测试全流程集成工具，定位Postman + Swagger + Mock + JMeter。通过一套系统、一份数据，解决多个系统之间的数据同步问题。只要定义好接口文档，接口调试、数据 Mock、接口测试就可以直接使用，无需再次定义；接口文档和接口开发调试使用同一个工具，接口调试完成后即可保证和接口文档定义完全一致。高效、及时、准确！ 二、功能 接口设计：Apifox 接口文档遵循OpenApi3.0 (原 Swagger)、JSON Schema规范的...
接口自动化测试工具-Apifox 基础篇：简介
白天像蚂蚁一样工作，晚上像蝴蝶一样生活
01-07 5571
1. 接口测试的需求 2. 常用解决方案 3. 存在的问题 存在的问题存在 开发人员在 Swagger 定义好文档后，接口调试的时候还需要去 Postman 再定义一遍。 前端开发 Mock 数据的时候又要用 Mock 工具定义一遍，还需要手动设置 Mock 规则。 测试人员需要去 JMeter 再定义一遍。 前端根据 RAP Mock 出来的数据开发完，后端根据 Swagger 定义的接口文档开发完，各都试测试通过了，本以为可以马上上线，结果一对接发现各种问题： ..
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值