This is the 7th day of my participation in the August Text Challenge.More challenges in August

  • 🥱 still in hand masturbation interface? Come to the whole interface request generator! (on)
  • 🥱 still in hand masturbation interface? Come to the whole interface request generator! (below)

background

In today’s projects where the front end is separated from the front end, one of the workload that the front end often has to do is to sort out a bunch of APIS and configure them into the project. And there are API modifications and updates, which will take a lot of time, not to mention the occasional hand damage caused by the problem is easy to despair.

So the question is, do we really have to write apis by hand? Is there a way to automatically generate the relevant structure configuration files? These are the problems we need to solve.

Swagger

Swagger is the first thing we’ll talk about today, and it’s estimated that many projects now use Swagger to generate back-end interface documents. The advantage of Swagger is that there is a standard way to generate a consistent standard configuration data regardless of the back-end interface structure.

Since Swagger generates consistent configuration data, how can we leverage it? Let’s look at Swagger’s interface

Swagger displays all of our open interfaces in a uniform structure, where we can see the address of the interface, the required parameters, the type of request and the return value.

Swagger also provides a digital display

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: "[email protected]"
  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"
   .
Copy the code

We can see that the data in the YAML file is exactly what we want, what structure we can extract from it, the request type of each interface, the address of the request, etc., and if we have this information we can use it to generate the relevant code for the request.

However, how to obtain such information? One is to generate YAML or JSON file through the export function of Swagger document. If the document is updated, we need to generate the export again. There is also the Swagger API to get interface information.

[s] HTTP: / / s [wagger address] / [v2 | v3] / API docsCopy the code

Swagger has an API-docs interface, through which we can obtain the corresponding JSON structure interface data, so we can directly call this interface when we need to obtain the latest interface data, and we need to pay attention to whether the version of Swagger is correct.

The data structure

Let’s start by looking at what data the Swagger API returns is useful to us

  • host
  • basePath
  • tags
  • paths

Host is the domain name or address of the current service. For microservices, basePath will be the corresponding public path,tags will have some manually marked description information, and Paths will be our main interface information.

Let’s take a look at what data items are in paths

. paths:{ [path]:{ [method]:{ tags:[...] , summary:... , description: ... , operationId: ... , produces: [...] , responses: ... , parameters: ... , deprecated:false}}}...Copy the code

Paths is an object where the key is the address path of the request and the next level is also an object where the key is the method request of the interface and its value is also an object where summary is usually the description and parameters are the request parameters.

We can see what we have

  • host
  • basePath
  • path
  • method

We have been able to construct the address of the request we need, and how the request should be made.

Generate configuration

Before we are ready to generate the interface request file, let’s prepare some configuration files

module.exports = {
  "gateway": "http://gateway.xxx.com"."apiVersion:": "v2"."controllerDir": {
    "alias": ".. /controller".// Controller directory name
    "path": "./src/controller"  // Controller directory path
  },
  "serviceDir": {
    "alias": "@/http/services".// Service directory name
    "path": "./src/services" // Service directory name
  },
  services: {"service-1":"service-1"."service-2":"service-2"."service-3":"service-3"}}Copy the code
  • gateway

We need to set the Swagger API address we need to request via the Gateway

  • apiVersion

Specifies the corresponding Swagger version

  • services

If you use a single service, you don’t need this configuration. Here, we assume that we use a micro service. Here, we configure the corresponding address and name of each service

  • controllerDir

Controller file generation directory

  • serviceDir

Service file generation directory

Since my network request uses the @gopowerTeam/HTTP-Request library, the request of this library needs to have a Controller file to configure the interface and a service file to send the request, so I need to set the directory to generate the corresponding file I need.

It can be seen that our plan is to obtain the interface information through Swagger API, and then generate the corresponding Controller file and service file through the interface data, so that we can no longer manage the configuration of the specific interface address in the business code, and directly call the service file to send the network request.

const userService = new UserService()

userService.login(new RequestParams()).subscribe({
    next: data= > {
        console.log(data)
    }
})
Copy the code

In the next section we will look at the day sum to automatically generate the relevant request configuration code.

Source address: Github

If you feel this article is helpful to your words might as well 🍉 attention + like + favorites + comments + forward 🍉 support yo ~~😛