api接口和后台管理（后端API）

网友投稿 1912 2023-02-16


本篇文章给大家谈谈api接口和后台管理，以及后端API对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享api接口和后台管理的知识，其中也会对后端API进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

A、B服务器系统为乌班图，A是api接口 和数据库，B是管理后台，要怎么实现B访问到A的数据库？

两种办法

一:

A上做接口,提供给B用

B程序中使用的所有和数据相关的操作都以API访问形式发送给A,等A处理好了返回.

如果你是PHP语言代码.直接使用file_get_contents来直接连接A上的接口就能获取A上的数据.A上的接口应该都是一些操作类.接收参数,返回数据.

例如:

A服务器:

<?php
//io.php
$a=$_GET['a'];//获取操作
if($a=='getname'){
   getname();
}
function getname(){
    $uid=$_GET['uid'];
    //搜索数据库获取数据
    echo '{"name":"王大春"}';//这里使用直接输出,如果是数组等复杂类型数据采用json输出
}

B服务器:

<?php
$data=file_get_contents('服务器地址/io.php?a=getnameuid=1');
//解析$data里的json数据
//处理数据

二:

A服务器上的数据库开放一个接口,对外.指定B服务器可以访问(防火墙设置B服务器可以访问数据库端口)然后B直接连接A服务器数据库即可.

对接API是什么意思？

API：应用程序接口（API：Application Program Interface）
应用程序接口（API：application programming interface）是一组定义、程序及协议api接口和后台管理的集合api接口和后台管理，通过 API 接口实现计算机软件之间的相互通信。API 的一个主要功能是提供通用功能集。程序员通过使用 API 函数开发应用程序api接口和后台管理，从而可以避免编写无用程序，以减轻编程任务。
API 同时也是一种中间件，为各种不同平台提供数据共享。根据单个或分布式平台上不同软件应用程序间的数据共享性能

Api接口管理工具推荐

在App开发过程中少不了跟服务端打交道，各种HTTP接口调试、返回数据处理占据了不少开发时间，一款好的接口管理工具就非常有必要了。接口管理工具一方面起到链接后台开发人员和App开发人员的作用，另一方面也可以作为传统的接口文档使用，且比文档的实时性更强。

因为各个团队的情况不太一样，可能对接口管理有不一样的需求，目前有不少接口管理工具，足以覆盖不同团队的需求，下面来简单介绍一下。

1. YApi
https://github.com/YMFE/yapi
YApi是由去哪网前端团队开源的一款接口管理工具，功能强大，可以轻松的自己部署。而且支持使用docker部署，使用成本很低了。

使用docker部署可以参考这篇文章： https://www.jianshu.com/p/a97d2efb23c5

2. Rap2
https://github.com/thx/rap2-delos
Rap2是由阿里妈妈前端团队开源的一款接口管理工具，相对YApi来说，至少文档上面差一些，Github上没有太多介绍，也没提及用docker部署，但也是一个选择吧。

3. eolinker
https://www.eolinker.com/
eolinker是一个接口管理服务网站，如果不想自己部署YApi、Rap2的团队可以使用，免费版的功能对于小型团队来说足够了。

4. Postman
https://www.getpostman.com/
跨平台的管理工具，可以免费使用，支持mock，支持团队协作，免费版本的限制主要在于每个月1000次的限制，包括Mock请求、API请求等等，对于小型团队（3～5人）应该是足够了。

5. Paw
https://paw.cloud/
仅支持Mac平台，可以试用30天，正式版要49.99美元，不是特别推荐使用，毕竟不能跨平台。

以上几个都能满足我们对于接口管理的需求，综合来看，多数团队可以直接使用eolinker提供的服务，Postman也可以，但是考虑到国内的网络情况并不推荐。对于有一定技术实力的团队可以使用YApi、Rap2，自己部署，甚至二次开发满足团队需求。

api接口程序的管理方式

API管理最重要的方面包括检测，分析和报告。传统的管理格言是，“无法管理没有指标的东西。”如果企业不仅仅满足于暴露API和服务，而是要管理他们，必须要度量关键指标，并将其应用到决策制定流程里。
度量不仅仅是设置一些阀值，并且在红色警报出现时做出反应。如果没有定期收集数据、分析并且用于决策制度，企业可能能做的更多只是做出反应，而不是真正的管理。要管理API，管理工具要能够完全提供健壮的能够驱动管理决策的数据集。网关管理工具收集使用信息，验证使用在合约限制之内，如果不是，就相应拒绝或者节流该请求。要达到这个目标，指标必须完全基于流量检测。这需要涉及到比如请求数量，相应事件和消息大小。

如何重构出这么优雅后台 API 接口

Hello，早上好，我是阿粉~

最近偶然间在看到 Spring 官方文档的时候，新学到一个注解 @ControllerAdvice ，并且成功使用这个注解重构我们项目的对外 API 接口，去除繁琐的重复代码，使其开发更加优雅。

展示具体重构代码之前，我们先来看下原先对外 API 接口是如何开发的。

这个 API 接口主要是用来与我们 APP 交互，这个过程我们统一定义一个交互协议，APP 端与后台 API 接口统一都使用 JSON 格式。

另外后台 API 接口对 APP 返回时，统一一些错误码，APP 端需要根据相应错误码，在页面弹出一些提示。

下面展示一个查询用户信息返回的接口数据：

code 代表对外的错误码， msg 代表错误信息， result 代表具体返回信息。

前端 APP 获取这个返回信息，首先判断接口返回 code 是否为 「000000」 ，如果是代表查询成功，然后获取 result 信息作出相应的展示。否则，直接弹出相应的错误信息。

下面我们来看下，重构之前的，后台 API 层的如何编码。

上面的代码其实很简单，内部统一封装了一个工具类 APIResult ，然后用其包装具体的结果。

除了这个以外，还定义一个异常对象 APPException ，用来统一包装内部的各种异常。

上面的代码很简单，但是呢可以说比较繁琐，重复代码也比较多，每个接口都需要使用 try...catch 包装，然后使用 APIResult 包括正常的返回信息与错误信息。

第二呢，接口对象只能返回 APIResult ，真实业务对象只能隐藏在 APIResult 中。这样不太优雅，另外不能很直观知道真实业务对象。

下面我们开始重构上面的代码，主要目的是去除重复的那一坨 try...catch 代码。

这次重构我们需要使用Spring 注解 @ControllerAdvice 以及 ResponseBodyAdvice ，我们先来看下重构的代码。

首先我们需要实现 ResponseBodyAdvice ，实现我们自己的处理类。

实现上面的接口，我们就可以在 beforeBodyWrite 方法里，修改返回结果了。

上面代码中，只是简单使用 APIResult 包装了返回结果，然后返回。其实我们还可以在此增加一些额外逻辑，比如说如接口返回信息由加密的需求，我们可以在这一层统一加密。

另外，这里判断一下 body 是否 APIResult 类，如果是就直接返回，不做修改。

这么做一来兼容之前的老接口，这是因为默认情况下，我们自己实现的 CustomResponseAdvice 类，将会对所有的 Controller 生效。

如果不做判断，以前的老接返回就会被包装了两层 APIResul ,影响 APP 解析。

除此之外，如果大家担心这个修改对以前的老接口有影响的话，可以使用下面的方式，只对指定的方法生效。

首先自定义一个注解，比如说：

然后将其标注在需要改动的方法中，然后我们在 ResponseBodyAdvice#supports 中判断具体方法上有没有自定义注解 CustomResponse ，如果存在，返回 true ，这就代表最后将会修改返回类。如果不存在，则返回 false ，那么就会跟以前流程一样。

上面的代码重构之后，将重复代码抽取了出来，整体的代码就剩下我们的业务逻辑，这样就变得非常简洁优雅。

不过，上面的重构的代码，还是存在问题，主要是异常的处理。

如果上面的业务代码抛出了异常，那么接口将会返回堆栈错误信息，而不是我们定义的错误信息。所以下面我们这个，再次优化一下。

这次我们主要需要使用 @ExceptionHandler 注解，这个注解需要与 @ControllerAdvice 一起使用。

使用这个 @ExceptionHandler ，将会拦截相应的异常，然后将会调用的相应方法处理异常。这里我们就使用 APIResult 包装一些错误信息返回。

我们可以使用 @ControllerAdvice 加 ResponseBodyAdvice 拦截返回结果，统一做出一些修改。这样就可以使用的业务代码非常简洁，优雅。

另外，针对业务代码的中，我们可以使用 @ExceptionHandler 注解，统一做一个全局异常处理，这样就可以无缝的跟 ResponseBodyAdvice 结合。

不过这里需要一点，我们实现的 ResponseBodyAdvice 类，一定需要跟 @ControllerAdvice 配合一起使用哦，至于具体原因，下篇文章阿粉分析原来的时候，再具体解释哦。敬请期待哦~

关于api接口和后台管理和后端API的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 api接口和后台管理的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于后端API、api接口和后台管理的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。

标签：接口文档 接口管理工具 接口管理 api 接口调试
上一篇:局域网做共享文件夹怎么设置（局域网做共享文件夹怎么设置）
下一篇:使用watch监听路由变化和watch监听对象的实例
相关文章

 发表评论

暂时没有评论，来抢沙发吧~