这是我参与8月更文挑战的第7天,活动详情查看:8月更文挑战
背景
在现在前后端分离的工程中,前端常常逃不过的一个工作量就是需要把一堆API接口进行整理,配置到项目中.而且在这其中很包含着API的修改,更新,这些工作都会耗费大量的时间,更不用说偶尔的手残导致的问题更是容易让人绝望.
那么我们的问题就是,我们有必要一定要手写API么?,有没有办法可以自动的生成相关的结构配置文件?这些都是我们需要解决的问题.
Swagger
今天首先要提到的就是Swagger,现在估计很多的项目都会使用Swagger来生成后端接口文档.Swagger的好处就是不管后端接口结构如何,都可以一种标准的方式来生成一种一致的标准配置数据.
既然Swagger生成了一致的配置数据,那我们应该如何利用他,我们先来看看Swagger的界面
Swagger把我们所有开放的接口以统一的结构进行了显示,我们可以看到接口的地址,需要的参数,以及请求的类型和返回值相关信息.
Swagger也提供了数据化的显示
swagger: "2.0"
info:
description: "This is a sample server Petstore server. You can find out more about Swagger at [http://swagger.io](http://swagger.io) or on [irc.freenode.net, #swagger](http://swagger.io/irc/). For this sample, you can use the api key `special-key` to test the authorization filters."
version: "1.0.0"
title: "Swagger Petstore"
termsOfService: "http://swagger.io/terms/"
contact:
email: "apiteam@swagger.io"
license:
name: "Apache 2.0"
url: "http://www.apache.org/licenses/LICENSE-2.0.html"
host: "petstore.swagger.io"
basePath: "/v2"
tags:
- name: "pet"
description: "Everything about your Pets"
externalDocs:
description: "Find out more"
url: "http://swagger.io"
- name: "store"
description: "Access to Petstore orders"
- name: "user"
description: "Operations about user"
externalDocs:
description: "Find out more about our store"
url: "http://swagger.io"
schemes:
- "https"
- "http"
paths:
/pet:
post:
tags:
- "pet"
summary: "Add a new pet to the store"
description: ""
operationId: "addPet"
consumes:
- "application/json"
- "application/xml"
produces:
- "application/xml"
- "application/json"
parameters:
- in: "body"
name: "body"
description: "Pet object that needs to be added to the store"
required: true
schema:
$ref: "#/definitions/Pet"
responses:
"405":
description: "Invalid input"
security:
- petstore_auth:
- "write:pets"
- "read:pets"
...
可以看到这个yaml文件中的数据就是我们想要的东西,我们可以从这里取出有哪些结构,每个接口的请求类型,请求地址等信息,如果有了这些信息我们也可以用来生成请求需要的相关代码.
但是如何获得这些信息呢,一个是通过Swagger文档的导出功能生成yaml或者json文件,如果文档更新这就需要我们重新来生成导出.还有一种就是通过Swagger API接口来获取接口信息.
http[s]://s[wagger地址]/[v2|v3]/api-docs
swagger有一个api-docs接口,通过这个接口我们就可以获取相应JSON结构的接口数据,这样我们需要获取最新的接口数据时直接调用这个接口即可,需要注意的Swagger的版本是否正确.
数据结构
我们先来看看Swagger API返回的数据哪些对我们有用
- host
- basePath
- tags
- paths
host是当前服务的域名或地址,如果是微服务那么basePath会是相应的公共路径,tags里会有一些手动标记的描述信息,而paths中是我们主要的接口信息.
我们再来看看一下paths中又有哪些数据项
...
paths:{
[path]:{
[method]:{
tags:[...],
summary:...,
description: ...,
operationId: ...,
produces: [...],
responses: ...,
parameters: ...,
deprecated: false
}
}
}
...
paths是一个对象,他的key就是path是对应请求的地址路径,对应的下一级也是一个对象,这里的key会是对应接口的method请求方式,它的值也是对象,其中summary一般是一些描述信息,parameters是请求参数.
我们可以看到我们拥有
- host
- basePath
- path
- method
我们已经可以构建出我们需要的请求地址,以及请求方式.
生成配置
在我们准备生成接口请求文件前,我们先来准备一些配置文件
module.exports = {
"gateway": "http://gateway.xxx.com",
"apiVersion:": "v2",
"controllerDir": {
"alias": "../controller", // 控制器目录名别
"path": "./src/controller" // 控制器目录路径
},
"serviceDir": {
"alias": "@/http/services", // 服务目录名别
"path": "./src/services" // 服务目录名别
},
services:{
"service-1":"service-1",
"service-2":"service-2",
"service-3":"service-3"
}
}
- gateway
我们需要通过gateway来设置我们需要请求的Swagger API地址
- apiVersion
指定对应的Swagger版本
- services
如果是使用单服务其实不需要这个配置,这里是假设我们使用了微服务,这里配置的是对应的每个服务地址和名称
- controllerDir
controller文件生成目录
- serviceDir
service文件生成目录
因为我的网络请求使用了@gopowerteam/http-request这个库,这个库的请求需要有一个用于配置接口的controller文件,以及一个发送请求的service文件,所有我需要设置目录来生成我需要的对应的文件.
可以看到我们的计划就是,希望通过Swagger API获取接口信息,然后通过接口数据来生成对应的controller文件和service文件,这样我们在业务代码中就可以不再管理具体接口地址的配置,直接调用service文件来发送网络请求.
const userService = new UserService()
userService.login(new RequestParams()).subscribe({
next: data => {
console.log(data)
}
})
之后的部分我们接着来看日和来自动生成相关的请求配置代码.
源码地址: github
如果您觉得这篇文章有帮助到您的的话不妨🍉关注+点赞+收藏+评论+转发🍉支持一下哟~~😛