前言 最近我司要制定开发规范.在讨论接口返回的时候,后端的同事询问我们前端,错误信息的返回,前端有什么意见? 所以做了一些调研给到后端的同事做参考. 错误信息返回 在使用API时无可避免地会因为各种情况而导致接口返回错误的信息.比如指定的query参数错误,又或者method不支持等,这些情况都会返回相关的错误信息.另外服务器不稳定或者停止运行了,也必须将错误信息返回. 显然,当错误发生的时候,只是笼统地返回"发生了错误"是不行的.如果前端不了解发生了什么错误,也就不知道该怎么去调试,

针对[API接口通讯参数规范]这篇文章留下的几个问题进行探讨. 问题1 试想一下,如果一个http请求返回一个500给我们,那我们是不是都不用看详情都知道该次请求发生了什么?这正是一个标准的结果码意义所在.在公司所有的系统中,API遵循同一套结果码,那这样同事A在调用同事B的接口时,对于返回的结果码是非常具有可读性的,我们不用面对面交流都知道返回的结果是一个什么样的情况. XML方案 在此先给出上一篇文章针对Result的另一个方案,是基于XML来定义结果码的,可能有些公司喜欢XML这种配置文件

Restful API 接口设计标准以及规范 RESTful概念 理解和评估以网络为基础的应用软件的架构设计,得到一个功能强.性能好.适宜通信的架构.REST指的是一组架构约束条件和原则." 如果一个架构符合REST的约束条件和原则,我们就称它为RESTful架构. REST本身并没有创造新的技术.组件或服务,而隐藏在RESTful背后的理念就是使用Web的现有特征和能力, 更好地使用现有Web标准中的一些准则和约束.虽然REST本身受Web技术的影响很深, 但是理论上REST架构风格并不是绑定

web api写api接口时默认返回的是把你的对象序列化后以XML形式返回,那么怎样才能让其返回为json呢,下面就介绍两种方法: 方法一:(改配置法) 找到Global.asax文件,在Application_Start()方法中添加一句: 复制代码 代码如下: GlobalConfiguration.Configuration.Formatters.XmlFormatter.SupportedMediaTypes.Clear(); 修改后: 复制代码 代码如下: protected void

通常在很多的公司里面,对于接口的返回值没做太大规范,所以会比较常看到各个项目各自定义随意的返回值,比如以下情况: 1. 直接返回bool值(True或者False) 2. 返回void,只要不是异常信息,默认成功 3. 返回各种状态码 4. 返回多个值,还要使用 out 来添加返回参数 5. ... 对于项目数量稍微多点的公司来说,接手多个项目的同事估计要吐血,所以项目间的业务通信规范是很有必要的.结合个人项目经验,定义一个专门用来封装返回值信息的通用类,如下: /// <summary> /

须要的引用的dll类: Newtonsoft.Json.dll.System.Net.Http.dll.System.Net.Http.Formatting.dll Web Api接口为GET形式: public static CstyleCmappListRespDTO GetCstyleCmappList(string cstylename, string cmappgname) { CstyleCmappListRespDTO RespDTO = new CstyleCmappListRe

物流接口 快递接口: http://www.kuaidi100.com/query?type=快递公司代号&postid=快递单号 ps:快递公司编码:申通="shentong" EMS="ems" 顺丰="shunfeng" 圆通="yuantong" 中通="zhongtong" 韵达="yunda" 天天="tiantian" 汇通="huit

希望给你3-5分钟的碎片化学习,可能是坐地铁.等公交,积少成多,水滴石穿,谢谢关注. 前后端分离的开发模式,假如使用的是基于RESTful API的七层通讯协议,在联调的时候,如何避免配合过程中出现问题?这里分享一些不成熟的浅见. Swagger描述 我们在前后端配合的过程中,使用了大多数人使用的Swagger作为服务描述文档,这样的好处很明显,就是后台编写注释,接口调用界面自动生成字段描述.如下图: 随着前后端磨合,默契程度逐步增加,基本上这种描述文档足够联调了.事物总是多变的,随着新人的加入

前言:已经有一个月没写点什么了,感觉心里空落落的.今天再来篇干货,想要学习Webapi的园友们速速动起来,跟着博主一起来学习吧.之前分享过一篇 WebApi 接口参数:传参详解,这篇博文内容本身很基础,没想到引起很多园友关注,感谢大家的支持.作为程序猿,我们都知道参数和返回值是编程领域不可分割的两大块,此前分享了下WebApi的传参机制,今天再来看看WebApi里面另一个重要而又基础的知识点:返回值.还是那句话:本篇针对初初使用WebApi的同学们,比较基础,有兴趣的且看看. 使用过Webapi

最近需要设计一个API服务器,想要把API接口搞得规范一下,就通过网上搜集到了一些资料,以下便是自己的一些理解以及相关的具体实现 本文采用的是spring boot+maven的方案 restful规范 这个规范我在这里也不打算长篇大论地讲解,怎么说呢,有人喜欢有人讨厌,我也不去争,因为我经验不多,看法和大佬有所不同. restful规范简单来说,就是通过一些关键字去定义url接口,从而让url具有更好的可读性,如下面举个例子 # 查询所有用户 http://localhost:9200/shu

上午在园子里乱逛,看了不少小伙伴们分享的接口测试方面的知识,大家所叙述到的一些经验或多或少,我也曾遇到过,突然意识到知识的点滴积累是多么的重要,我记得我最早接触接口测试的时候,就是只在浏览器里人工测试单个接口的返回结果,后来用python的unittest自己写测试框架,和现在大多数小伙伴们的方法差不多,测试用例也是存放在excle表中,这对于单人测试来说都还ok,但是如果是多人协同测试时,问题就出来了,因为按目录存放在不同的excle表中的测试用例,维护起来比较麻烦,而且不便于多人查询或共同维

上午在园子里乱逛,看了不少小伙伴们分享的接口测试方面的知识,仔细想想,我做接口测试也有几个年头了,大家所叙述到的一些经验或多或少,我也曾遇到过,突然意识到知识的点滴积累是多么的重要,我记得我最早接触接口测试的时候,就是只在浏览器里人工测试单个接口的返回结果,后来用python的unittest自己写测试框架,和现在大多数小伙伴们的方法差不多,测试用例也是存放在excle表中,这对于单人测试来说都还ok,但是如果是多人协同测试时,问题就出来了,因为按目录存放在不同的excle表中的测试用例,维护起

Swagger 生成 PHP API 接口文档 Lumen微服务生成Swagger文档 1.概况 有同学反馈写几十个接口文档需要两天的工作量, 随着多部门之间的协作越来越频繁, 维护成本越来越高, 文档的可维护性越来越差, 需要一个工具来管理这些接口的文档, 并能够充当mock server给调用方使用. 有同学推荐了swagger+easymock,Swagger是一个简单但功能强大的API表达工具. 这里介绍使用swagger-php生成PHP API文档的方法. 2.安装与使用 2.1 安

整体规范建议采用RESTful 方式来实施. 协议 API与用户的通信协议,总是使用HTTPs协议,确保交互数据的传输安全. 域名 应该尽量将API部署在专用域名之下.https://api.example.com 如果确定API很简单,不会有进一步扩展,可以考虑放在主域名下.https://example.org/api/ api版本控制 应该将API的版本号放入URL.https://api.example.com/v{n}/另一种做法是,将版本号放在HTTP头信息中,但不如放入URL方便和

上一篇文章(https://www.cnblogs.com/meowv/p/12916613.html)使用自定义仓储完成了简单的增删改查案例,有心的同学可以看出,我们的返回参数一塌糊涂,显得很不友好. 在实际开发过程中,每个公司可能不尽相同,但都大同小异,我们的返回数据都是包裹在一个公共的模型下面的,而不是直接返回最终数据,在返回参数中,显示出当前请求的时间戳,是否请求成功,如果错误那么错误的消息是什么,状态码(状态码可以是我们自己定义的值)等等.可能显得很繁琐,没必要,但这样做的好处毋庸置疑

目录 1.web应用模式 2.API接口 3.Restful API规范 4.序列化 5.Django Rest Framework 1.drf的简单介绍 2.drf的特点 3.如何安装drf 4.drf的强大之处 5.序列化器的使用 1.web应用模式 在开发Web应用中,有两种应用模式: 1.前后端不分离 2.前后端分离 2.API接口 为了在团队内部形成共识.防止个人习惯差异引起的混乱,我们需要找到一种大家都觉得很好的接口实现规范,而且这种规范能够让后端写的接口,用途一目了然,减少双方之间

api接口写好了?想过(Accept,Content-Type)?返回类型json|xml? 起因: - A,B. A调用B提供的api接口. - A:为毛你的接口返回的是xml格式的(浏览器访问)?给个json行不行? - B:没问题啊,我们自己的程序一直在用 测试 1. 测试demo 新建一个spring boot RESTful API项目 @RequestMapping(value = "/hello", method = RequestMethod.GET) public U

API 接口返回值 https://blog.csdn.net/baple/article/details/52925772

突然遇到的问题  就是使用Laravel进行开发API接口的时候  发现在表单验证不通过的时候返回了登录页 猜测问题应该是因为表单验证失败后进行了重定向导致的 因为返回状态码200 网上找了好久没找到相关解决方案 只能自己猜测一下解决问题 我在app\Http\Controller\Controller.class.php里面重写了validate这个方法 public function validate($request, $rules, $message){ $Validator = Val

开发同事反馈一个SQL Server存储过程执行的时候,报"链接服务器"(null)"的 OLE DB 访问接口 "SQLNCLI10" 返回了消息 "Cannot start more transactions on this session.".这个存储过程,个人做了一个精简和脱敏处理后如下: BEGIN TRY     BEGIN TRANSACTION                            INSERT INTO