Introduction à Swagger
Swagger est en effet une bonne chose. Il peut générer automatiquement des documents d'interface API basés sur le code commercial, en particulier pour les projets dans un style Restful. Les développeurs peuvent difficilement avoir à maintenir l'API Restap spécifiquement. Ce cadre peut générer automatiquement des API de style repos pour votre code commercial, et fournit également une interface de test correspondante pour afficher automatiquement la réponse au format JSON. Il facilite considérablement les coûts de communication et de coordination entre les développeurs backend et le front-end.
Introduction à Springfox-Swagger
Avec les fonctions puissantes de Swagger, le grand cadre de printemps de l'industrie open source Java s'est rapidement tenu. Il a pleinement utilisé ses propres avantages, a intégré Swagger dans son propre projet et a intégré un printemps-saut, qui a ensuite évolué vers Springfox. Springfox lui-même utilise uniquement ses propres caractéristiques AOP et intègre Swagger dans la prise. Sa propre génération d'API d'entreprise compose toujours sur Swagger pour y parvenir.
Il y a relativement peu d'informations sur ce cadre, et la plupart d'entre eux sont une utilisation simple de niveau d'entrée. J'ai rencontré de nombreux pièges dans le processus d'intégration de ce cadre dans mon projet. Afin de résoudre ces pièges, j'ai dû déterrer son code source pour voir ce qu'il était. Cet article décrit ma compréhension de Springfox et à quoi il faut prêter attention lors de l'utilisation de Springfox.
Le principe général de Springfox
Le principe général de Springfox est que dans le processus de démarrage du projet, pendant le processus d'initialisation du contexte de Spring, le cadre charge automatiquement certains haricots liés à Swagger dans le contexte actuel en fonction de la configuration et analyse automatiquement les classes qui peuvent avoir besoin de générer des documents API dans le système et génère le cache d'information correspondant. Si la couche de contrôle MVC du projet utilise SpringMVC, elle analysera automatiquement toutes les classes de contrôleur pour générer des documents API correspondants en fonction des méthodes de ces classes de contrôleur.
Étant donné que mon projet est SpringMVC, cet article utilise Srping MVC Intégration Springfox comme exemple pour discuter de l'utilisation et des principes de Springfox.
Étapes pour intégrer SpringMVC dans Springfox
Tout d'abord, le projet doit ajouter les trois dépendances suivantes:
<! - Sring MVC Dependency -> <Dedency> <GroupId> org.SpringFramework </proupId> <ArtifActid> printemps-webmvc </ artifactid> <version> 4.2.8.release </preint> </Dependance> <! - Swagger2 Corentency -> <Dedency> <proupId> io.springfox </prouprid> <ArtefactId> Springfox-swagger2 </letefactive> <version> 2.6.1 </ version> </dependency> <! - Swagger-Ui fournit une interface d'affichage API et de test pour les projets -> <Dedency> <ProupID> io.springfox </proncID> <Artifactid> SpringFox-Swagger-Ui </ArtifActid> <Dusion> 2.6.1;
Les trois dépendances ci-dessus sont les dépendances les plus élémentaires pour l'intégration de projet SpringMVC et Springfox, et d'autres dépendances sont omises ici. Le premier est la dépendance de base de SpringMVC, la seconde est la dépendance de la fanfaronnage, et la troisième est la dépendance liée à l'interface. Ce n'est pas nécessaire. Si vous ne souhaitez pas utiliser l'interface API qui est livrée avec Springfox, vous ne pouvez pas non plus l'utiliser et écrire un ensemble d'interfaces qui conviennent à votre projet. Après avoir ajouté ces dépendances, le système ajoutera automatiquement des packages JAR liés à Springfox et Swagger. J'ai jeté un bref coup d'œil et j'ai constaté qu'il y avait principalement ce qui suit:
Springfox-Swagger2-2.6.1.jar
Swagger-Annotations-1.5.10.jar
swagger-modes-1.5.10.jar
Springfox-SPI-2.6.1.jar
Springfox-core-2.6.1.jar
Springfox-Schema-2.6.1.jar
Springfox-Swagger-Common-2.6.1.jar
Springfox-Spring-Web-2.6.1.jar
goyave-17.0.jar
printemps-plugin-core-1.2.0.release.jar
printemps-Plug-Metadata-1.2.0.release.jar
Spring-Swagger-UI-2.6.1.jar
jackson-databind-2.2.3.jar
Jackson-Annotations-2.2.3.jar
Ce qui précède est les pots dont je pense visuellement que Springfox peut avoir besoin et peut ne pas illustrer complètement tous les pots dont Springfox a besoin. Depuis le pot ci-dessus, nous pouvons voir qu'en plus de compter sur Swagger, Pringfox nécessite également des goyaves, du printemps-plug, de Jackson et d'autres dépendances (notez que Jackson est un package de pot nécessaire pour générer JSON. Si cette dépendance n'est pas ajoutée au projet lui-même, afin d'intégrer Swagger, cette dépendance doit être ajoutée).
Utilisation simple de Springfox
Si vous n'utilisez que la configuration par défaut de SpringFox, l'intégration avec SpringMVC est très simple. Écrivez simplement une classe similaire au code suivant et mettez-le dans votre projet. Le code est le suivant:
@ Configuration @ activerwebmvc @ ActivedWagger2PublicClass ApiConfig {}Notez que ci-dessus est un fichier de classe Java vide, le nom de classe peut être spécifié à volonté, mais les trois annotations marquées @configuration, @enablewebmvc et @ activewagger2 dans la classe ci-dessus doivent être ajoutées. Cela complète l'intégration de base de SpringMVC et Springfox. Avec trois annotations, après le début du projet, vous pouvez directement utiliser une adresse similaire à ce qui suit pour afficher la liste des API: http://127.0.0.1:8080/jaddemo/swagger-ui.html
C'est en effet un effet très magique. Avec trois annotations simples, le système affichera automatiquement toutes les API de toutes les classes de contrôleur du projet. Maintenant, commençons par cette classe de configuration et analysons simplement ses principes. Il n'y a pas de code dans cette classe, et il est évident que les trois annotations jouent un rôle crucial. Parmi eux, l'annotation @configuration est déjà disponible dans le cadre de printemps. Il s'agit d'une annotation identifiée par la méta-annotation @component. Par conséquent, avec cette annotation, le printemps instanciera automatiquement la classe dans un haricot et l'enregistrera dans le contexte du printemps. La deuxième annotation @enablewebmvc signifie donc que Srpingmvc est activé. Cliquez sur cette annotation dans Eclipse pour un bref aperçu. Il s'agit de fourrer un bean de type déléguant webmvcconfiguration dans le contexte de printemps via la méta annotation @Import (délégationwebmvcconfiguration.class). Je pense que le but de cette classe devrait être de fournir à Swagger une certaine configuration SpringMVC. La troisième annotation: @ activewagger2. Vous pouvez penser au nom. Il est utilisé pour intégrer Swagger 2. Grâce à la méta-annotation: @Import ({Swagger2DocumentationConfiguration.class}), il a introduit un bean de configuration de type Swagger2DocumentationConfiguration, et il s'agit de la configuration centrale de Swagger. Le code à l'intérieur est comme suit:
@ Configuration @ import ({springfoxwebmvcconfiguration.class, swaggercommonconfiguration.class}) @ composantscan (basepackages = {"springfox.documentation.swagger2.readers.Parameter", "Springfox.documentation.wagger.wagre", "Springfox.Documentation.Swagger2.Mappers"}) publicClassSwagger2DocumentationConfiguration {@bean public JacksonModuleGistrar Swagger2Module () {returnNewswagger2JacksonModule (); }}Cet en-tête de classe utilise des annotations, puis présente la classe SpringFoxWebmvcConfiguration et la classe SwaggerCommonConfiguration, et analyse automatiquement les haricots liés à Springfox .wagger2 dans le contexte de printemps via l'annotation des composants. Ici, ce qui m'intéresse le plus, c'est la classe SpringfoxWebmvcConfiguration. Je suppose que cette classe devrait être la configuration plus centrale de SpringFox intégrée MVC. Cliquez sur et voir le code suivant:
@ Configuration @ import ({ModelsConfiguration.class}) @ ComponentsCan (basepackages = { "Springfox.Documentation.spring.web.scanners", "Springfox.Documentation.spring.web.readers.Operation", "Springfox.Documentation.spring.web.readers.Operation", "Springfox.Documentation.spring.Parameter", "Springfox.Documentation.spring.web.plugins", "Springfox.Documentation.spring.web.paths"}) @vablepluginRegistries ({{ Documentationplugin.class, apilistingbuilderplugin.class, operationbuilderplugin.class, paramètrebuilderplugin.class, expansagePaMeterBuilderplugin.class, ResourceGroupingStrategin.class, opérationmodelsproviderplugin.class, defaultproviderplugin.classe, class, Pathdecorator.class}) publicClassSpringFoxwebmvcConfiguration {}Le code suivant de cette classe n'est rien de plus que d'ajouter de nouveaux haricots via l'annotation @Bean. Je n'y suis pas très intéressé. Ce qui m'intéresse le plus, ce sont les choses ajoutées à la tête via @enablepluginRegistries. Springfox est basé sur le mécanisme de printemps pour intégrer Swagger. Comment le printemps-Plug est-il mis en œuvre? Je n'ai pas encore le temps d'étudier le principe du printemps. Mais ci-dessous, je mentionnerai que j'écris un plugin de plug pour étendre les fonctionnalités de Swagger. La prise ajoutée ci-dessus via @enablePlugInRegistries n'est pas encore disponible. Les codes que j'ai vus incluent principalement apilistingbuilderplugin.class, operationbuilderplugin.class, paramètrebuilderplugin.class, expandingParameterBuilderplugin.class, expansagePaMeterBuilderplugin.class,
Le premier apilistebuilderplugin, qui possède deux classes de mise en œuvre, à savoir leader apiliste et swagerapilistingReader. Parmi eux, leader apiliste générera automatiquement une liste d'API selon le type de contrôleur, et leader SwagerapilistingRa générera une liste d'API selon la classe identifiée par l'annotation @API. Le plugin OperationBuilderPlugin est utilisé pour générer des documents API spécifiques. Ce type de plugin propose de nombreuses classes d'implémentation. Ils divisent chacun leur travail et font leurs propres choses. Je n'ai pas examiné attentivement les détails, mais je me suis concentré uniquement sur l'une des classes d'implémentation: OperationParameTerReader. Cette classe est un plugin utilisé pour lire les paramètres de l'API. Il s'appuie sur la classe d'outils ModelAtTRributeParameTerexpander, qui peut analyser automatiquement les objets de commande de type non simple dans les paramètres de la méthode d'interface du contrôleur pour obtenir une liste de paramètres contenant tous les attributs (il y a ici une fosse qui peut provoquer une récursion infinie, qui est introduite ci-dessous). Le plug-in ExpandedParameterBuilderPlugin est principalement utilisé pour étendre certaines fonctions des paramètres d'interface, tels que la détermination du type de données de ce paramètre et s'il s'agit d'un paramètre nécessaire pour cette interface, etc. Dans l'ensemble, l'ensemble de SpringFox-Swagger est en fait transporté par cette série de bouchons. Lorsque le système démarre, ils sont réglés, certains sont utilisés pour scanner la liste des interfaces, certains sont utilisés pour lire les paramètres d'interface, etc. Leur objectif commun est de scanner toutes les interfaces API du système et de les mettre en cache pour les utilisateurs. Alors, comment cette série de bouchons de table est-elle réglée et où sont leurs entrées d'exécution?
Nous mettons notre point d'attention sur le contenu d'annotation des composants à l'en-tête de code de la classe SpringfoxWebmvcConFiguration ci-dessus. Dans cette annotation, un package appelé Springfox.Documentation.spring.web.plugins est scanné. Ce package se trouve dans Springfox-Spring-web-2.6.1.jar. Dans ce package, nous avons constaté qu'il existe deux classes très de base, à savoir DocumentationPluginsManager et DocumentationPluginsbootstrapper. Pour la première documentation PluginsManager, c'est un bean qui n'implémente aucune interface, mais il a de nombreuses propriétés de type de plugin registre, et toutes sont injectées dans la valeur de la propriété via l'annotation @Autowired. En combinant son nom de classe, il est facile de penser qu'il s'agit d'un gestionnaire qui gère toutes les bouchons. Il est facile à comprendre, en raison de la configuration de l'annotation des composants de la SCAN, toutes les instances de fiche seront instanciées dans un haricot par printemps, puis injectées dans cette instance de documentation PluginsManager et gérées uniformément. Une autre classe importante de ce package documentation Pluginsbootstrapper, vous pouvez deviner qu'en regardant le nom, c'est peut-être la classe de démarrage de Plug. Lorsque vous cliquez sur et regardez les détails, vous constaterez qu'il s'agit en effet d'un composant identifié par @Component, et sa méthode de construction injecte l'instance DocumentationPluginsManager, et la chose la plus critique est qu'elle implémente également l'interface SmartLifecycle. Quiconque connaît le cycle de vie des haricots de printemps sait que lorsque ce composant est instancié dans un haricot et est géré dans le contexte Srping, sa méthode start () sera automatiquement appelée. Lorsque vous cliquez sur start () pour regarder le code, vous constaterez qu'il a un scandocumentation de code (buildContext (chacun)); qui est utilisé pour scanner les documents d'API. En suivant davantage le code de cette méthode, vous pouvez constater que cette méthode utilisera finalement sa propriété DocumentationPluginsManager pour ajuster toutes les fiches ensemble pour scanner l'ensemble du système et générer des documents API. Les résultats de numérisation sont mis en cache dans une propriété MAP de la classe DocumentationCache.
Ce qui précède est le principe général de SRPINGMVC intégrant Springfox. Il injecte principalement une série de haricots dans le contexte SRPP à travers l'annotation Activeablewagger2 et analyse automatiquement la classe de contrôleur du système lorsque le système démarre, génère des informations API correspondantes et les met en cache. De plus, il injecte certaines classes de contrôleur identifiées par @Controller Annotation comme l'entrée du module d'interface utilisateur pour accéder à la liste des API. Par exemple, la classe Swagger2Controller dans le package Springfox-Swagger2-2.6.1.jar. Ce contrôleur est l'adresse d'interface utilisée dans le module d'interface utilisateur pour accéder à la liste des API. Lorsque vous visitez l'adresse http://127.0.0.1:8080/jaddemo/swagger-ui.html pour afficher la liste des API, vous pouvez voir via le navigateur qu'il obtient de manière asynchrone les informations API (format JSON) par le biais d'une adresse à http://127.0.0.1:8080/jaddemo/v2/api-docs?group=SYSGROUP et l'affichage sur l'interface. L'entrée du contrôleur correspond à l'arrière-plan de cette adresse est la classe Swagger2Controller ci-dessus. Après avoir reçu la demande, cette classe récupère directement les informations de l'API à partir du cache qui a été initialisée à l'avance pour générer un retour de chaîne JSON.
Après avoir compris les principes de Springfox, jetons un coup d'œil aux pièges que j'ai rencontrés lors de l'utilisation de Springfox.
La première grande fosse de Springfox: le bean généré par la classe de configuration doit partager le même contexte que Spring MVC.
Comme décrit ci-dessus, dans le projet SpringMVC, l'intégration de SpringFox est juste pour écrire une classe de configuration simple comme suit sans aucun code commercial dans le projet.
@ Configuration @ activerwebmvc @ ActivedWagger2PublicClass ApiConfig {}En raison de l'annotation @configuration, le printemps l'instnera automatiquement dans un haricot et l'injectera dans le contexte. Mais un piège à noter est que le contexte dans lequel ce haricot doit être dans le même contexte que le printemps MVC. Comment comprendre? Parce que dans les projets Spring MVC réels, il y a généralement deux contextes, l'un suit le contexte et l'autre est Spring MVC (c'est un sous-contexte qui suit le contexte). Le contexte est le org.springframework.web.context.request.requestContextListener lié à Spring dans le fichier web.xml. Le contexte chargé est généralement écrit comme un fichier de configuration appelé Spring-Contt.xml. Les haricots ici seront finalement initialisés dans le contexte. Il comprend principalement le service, le DAO et d'autres haricots dans le système, ainsi que les sources de données, les choses, etc. Un autre contexte est Spring MVC, qui est chargé via le org.springframework.web.servlet.dispatcherServlet lié à Spring MVC dans web.xml. Il a généralement un fichier de configuration appelé Spring-Mvc.xml. Lors de la rédaction de la classe ApiConfig, si nous décidons de le charger avec l'annotation @configuration, nous devons nous assurer que le chemin de cette classe se situe dans la portée du package de base de la configuration de l'écran du composant dans SpringMVC. Parce que lorsque Apiconfig est chargé par le ressort, une série de haricots sera injectée. Dans ces haricots, afin de numériser automatiquement toutes les classes de contrôleur, certains haricots doivent compter sur certains haricots de SpringMVC. Si le projet sépare le contexte de Srpingmvc à partir du contexte en tant que sous-contexte du contexte. Si vous laissez accidentellement ce bean de type apiconfig être chargé du texte précédent, car il n'y a pas de classes de configuration dans le contexte Spring MVC dans le contexte racine.
En fait, je ne suis pas d'accord avec la configuration de Swagger via l'annotation @configuration, car je pense que la fonctionnalité de l'API de Swagger est facultative pour les projets de production. Notre fanfaron est souvent utilisé pour tester des environnements pour le développement d'équipe frontal du projet ou pour d'autres systèmes pour intégrer les interfaces. Une fois le système en ligne, il est probable que ces listes d'API seront cachées sur le système de production. Mais si la configuration est écrite dans le code Java via l'annotation @configuration, alors lorsque vous souhaitez supprimer cette fonction lorsque vous vous rendez en ligne, ce sera embarrassant et vous devez modifier le code Java pour vous recompiler. Sur la base de cela, je recommande une méthode pour configurer le fichier XML le plus traditionnel par Spring. La méthode spécifique consiste à supprimer l'annotation @configuration, puis il écrit une configuration de bean similaire à <Bean /> dans le fichier de configuration Spring XML. Dans un projet où le contexte racine est séparé du contexte MVC, il est directement configuré en printemps-mvc.xml, qui garantit qu'il doit être dans le même contexte que le contexte SpringMVC.
La deuxième plus grande fosse de Springfox: les paramètres de la classe du contrôleur, prêtent attention pour empêcher la récursivité infinie.
Spring MVC a un puissant mécanisme de liaison des paramètres, qui peut lier automatiquement les paramètres de demande dans un objet de commande personnalisé. Par conséquent, pour être paresseux, de nombreux développeurs utilisent directement un objet entité comme paramètre de la méthode du contrôleur lors de l'écriture d'un contrôleur. Par exemple, l'exemple de code suivant:
@Requestmapping (value = "update") Update de la chaîne publique (menuvomenuvo, modèle modèle) {}Il s'agit du code que la plupart des programmeurs aiment écrire dans Controller pour modifier une entité. Lors de l'intégration avec Swagger, il y a une grosse fosse ici. Si toutes les propriétés de MENUVO sont des types de base, alors ça va, rien ne va mal. Mais s'il existe d'autres attributs de type personnalisé dans cette classe, et cet attribut existant directement ou indirectement les attributs de son propre type, il y aura des problèmes. Par exemple: si la classe MENUVO est une classe de menu, elle contient également un parent de propriété du type MENUVO qui représente son menu parent. De cette façon, le module Swagger rapportera directement une erreur au début du système car il ne peut pas charger l'API. La raison de l'erreur est que lors du chargement de cette méthode, les paramètres de la méthode de mise à jour seront analysés. Lorsque le paramètre MENUVO n'est pas un type simple, tous ses attributs de classe seront automatiquement interprétés récursivement. Cela permet de tomber facilement dans une boucle morte de récursivité infinie.
Afin de résoudre ce problème, je viens d'écrire une classe d'implémentation du plug-in de l'OperationParameTerReader et la classe d'outils ModelAtTRributeParameTerexpander dont il dépend. Il remplace les deux classes d'origine de SrpingFox via la configuration, remplace la logique de l'analyse de l'analyse des paramètres comme une colonne et évite la récursivité infinie. Bien sûr, cela équivaut à un moyen de modifier le niveau de code source. Je n'ai pas encore trouvé de solution plus parfaite à ce problème, donc je ne peux que recommander d'essayer d'éviter cette récursivité infinie lors de l'utilisation de Spring-Fox Swagger. Après tout, cela ne respecte pas les spécifications des objets de commande SpringMVC. Les objets de commande avec le paramètre SpringMVC ne sont de préférence que des attributs de type de base simples.
Troisième fosse majeure de Springfox: le regroupement des API, les instances de dossier ne peuvent pas être chargées de manière latente
Springfox divisera toutes les API en groupe par défaut. Lorsqu'il est accessible via une adresse similaire à http://127.0.0.1:8080/jaddemo/swagger-ui.html, toutes les listes d'API seront chargées sur la même page. De cette façon, si le système est un peu plus grand et que l'API est un peu plus, la page sera tracée à mort, il est donc très nécessaire de regrouper l'API. Le regroupement de l'API est défini par l'annotation @Bean dans le fichier de configuration ApiConf. Les configurations courantes sur Internet sont les suivantes:
@ Activerwebmvc @ ActivedWagger2PublicClass APICONFIG {@bean public Docket CustomDocket () {return newDocket (documentationType.swagger_2) .apiinfo (apiinfo ()); }}Dans le code ci-dessus, un dossier est injecté via @Bean. Cette configuration n'est pas nécessaire. Si cette configuration n'est pas disponible, le framework générera en soi une instance de dossier par défaut. Le but de cette instance de dossier est de spécifier les informations publiques de toutes les API qu'il peut gérer, telles que des informations de base telles que la version API, l'auteur, etc., et de spécifier quelles API sont répertoriées uniquement (filtrées par adresses API ou annotations).
Il peut y avoir plusieurs instances de dossier, telles que le code suivant:
@ Activerwebmvc @ ActivedWagger2PublicClass APICONFIG {@bean public Docket CustomDocket1 () {return newDocket (DocumentationType.Swagger_2) .GroupName ("apigroup1"). Apiinfo (apiinfo ()). Select (). Paths (pathSelectors.ant ("/ Sys / **")); } @Bean public Docket CustomDocket2 () {return newDocket (documentationType.swagger_2) .groupName ("apigroup2"). Apiinfo (apiinfo ()). Select (). Paths (pathselectors.ant ("/ shop / **")); }}Lorsque plusieurs instances de dossier sont configurées dans le projet, l'API peut être regroupée, par exemple, le code ci-dessus divise l'API en deux groupes. Dans ce cas, chaque groupe doit se voir attribuer un nom différent, tel que "apigroup1" et "apigroup2" dans le code ci-dessus. Chaque groupe peut utiliser des chemins pour spécifier le groupe pour gérer les API par l'expression d'adresse de style Ant. Par exemple, dans la configuration ci-dessus, le premier groupe d'adresses de gestion est des API avec le début de / sys /. Le deuxième groupe d'API de gestion avec le début de / shop /. Bien sûr, il existe de nombreuses autres méthodes de filtrage, telles que l'annotation de classe, l'annotation de la méthode, les expressions régulières, etc. Après le regroupement, vous pouvez sélectionner différents groupes d'API dans l'option déroulante dans le coin supérieur droit de l'interface de liste API. Cela dispersera la liste des API du projet à différentes pages. Cela facilitera la gestion sans prétendre être mort car la page doit charger trop d'API.
Cependant, comme l'utilisation de @configuration, je ne suis pas d'accord avec l'utilisation de @Bean pour configurer les instances de dossier pour regrouper les API. Pour cette raison, le code sera également écrit à mort. Je recommande donc de configurer votre propre instance de dossier dans le fichier XML pour implémenter ces fonctions similaires. Bien sûr, compte tenu des nombreux attributs du dossier, il est plus difficile de configurer directement les haricots. Vous pouvez écrire un FactoryBean pour le dossier vous-même, puis configurer FactoryBean dans le fichier XML. Cependant, lors de la configuration du dossier dans XML. Vous rencontrerez une autre grande fosse, c'est-à-dire que la méthode de chargement du ressort sur les haricots est chargée paresseuse par défaut. Après la configuration directe de ces beans d'instance de dossier dans XML. Vous constaterez qu'il n'y a aucun effet et qu'il n'y a pas d'élément de regroupement dans la liste déroulante dans le coin supérieur gauche de la page.
Ce problème m'a troublé pendant plusieurs heures. Plus tard, sur la base de l'expérience, il a été supposé que cela pourrait être dû au fait que le bean à ressort est un chargement paresseux par défaut, et cette instance de dossier n'a pas été chargée dans le contexte de ressort. En fait, je suppose que c'est correct. Je ne sais pas s'il s'agit d'un bug dans Springfox, ou si je n'aurais pas dû déplacer la configuration du dossier du code Java d'origine vers le fichier de configuration XML.
Autres pièges à Springfox: il y a d'autres pièges à Springfox. Par exemple, dans l'annotation @APIOperation, si l'attribut HttpMethod n'est pas spécifié comme une certaine méthode GET ou POST, toutes les méthodes telles que GET, Post, Supprimer, Put seront répertoriées dans la liste des API, afin que la liste des API soit trop dupliquée, ce qui est très laid. De plus, pendant les tests, j'ai rencontré des problèmes d'autorisation de connexion, etc. Ces piles de petites fosses qui sont plus faciles à résoudre, en raison de l'espace limité, je ne dirai pas grand-chose. Il y a aussi l'utilisation d'annotations telles que @API, @APIOperation et @apiparam. Je ne répéterai pas beaucoup de documents à ce sujet en ligne.
Ce qui précède est tout le contenu de cet article. J'espère que cela sera utile à l'apprentissage de tous et j'espère que tout le monde soutiendra davantage Wulin.com.