Swagger 소개
Swagger는 참으로 좋은 일입니다. 비즈니스 코드, 특히 편안한 스타일의 프로젝트에 기반한 API 인터페이스 문서를 자동으로 생성 할 수 있습니다. 개발자는 구체적으로 Restap API를 유지할 필요가 없습니다. 이 프레임 워크는 비즈니스 코드에 대한 RestFut 스타일 API를 자동으로 생성 할 수 있으며 JSON 형식의 응답을 자동으로 표시 할 수있는 해당 테스트 인터페이스를 제공 할 수 있습니다. 백엔드 개발자와 프론트 엔드 간의 커뮤니케이션 및 조정 비용을 크게 촉진합니다.
Springfox-Swagger 소개
Swagger의 강력한 기능으로 Java 오픈 소스 산업 Big Spring Framework는 빠르게 유지되었습니다. 자체 장점, 자체 프로젝트에 통합 된 Swagger를 완전히 활용했으며 Spring-Swagger를 통합하여 나중에 Springfox로 진화했습니다. Springfox 자체는 자체 AOP 특성 만 사용하고 Swagger를 플러그에 통합합니다. 자체 세대의 비즈니스 API는 여전히 Swagger에 의존하여이를 달성합니다.
이 프레임 워크에 대한 정보는 상대적으로 적으며 대부분은 엔트리 레벨 간단한 사용입니다. 이 프레임 워크를 프로젝트에 통합하는 과정에서 많은 함정을 만났습니다. 이러한 함정을 해결하기 위해서는 소스 코드를 파헤쳐 서 그것이 무엇인지 확인해야했습니다. 이 기사에서는 Springfox에 대한 나의 이해와 Springfox를 사용하는 동안주의를 기울여야 할 사항에 대해 설명합니다.
Springfox의 일반적인 원칙
Springfox의 일반적인 원칙은 프로젝트 시작 과정에서 스프링 컨텍스트의 초기화 과정에서 프레임 워크가 구성에 따라 일부 Swagger 관련 Beans를 현재 컨텍스트에 자동으로로드하고 시스템에서 API 문서를 생성하는 데 필요한 클래스를 자동으로 스캔하고 해당 정보 캐시를 생성한다는 것입니다. 프로젝트의 MVC 제어 계층이 SpringMVC를 사용하는 경우 모든 컨트롤러 클래스를 자동으로 스캔하여 해당 컨트롤러 클래스의 방법에 따라 해당 API 문서를 생성합니다.
내 프로젝트는 SpringMVC 이므로이 기사는 SRPing MVC Integration Springfox를 사용하여 Springfox의 사용 및 원리를 논의합니다.
SpringMVC를 Springfox에 통합하는 단계
먼저 프로젝트는 다음 세 가지 종속성을 추가해야합니다.
<!-Sring MVC 종속성-> <pectionency> <groupId> org.springframework </groupid> <artifactid> Spring-webmvc </artifactid> <bersion> 4.2.8. Release </version> </feencevency> <!-swagger2 core 종속성-> <groupid> io.sprox> <Artifactid> Springfox-Swagger2 </artifactid> <버전> 2.6.1 </version> </fectionency> <!-Swagger-UI는 프로젝트에 대한 API 디스플레이 및 테스트 인터페이스를 제공합니다-> <pectionement> <groupId> io.springfox </groupid> <artifactid> springfox-swagger-ui </artifactid>. </의존성>
위의 세 가지 종속성은 프로젝트 통합 SpringMVC 및 Springfox의 가장 기본적인 종속성이며 다른 종속성은 여기에서 생략됩니다. 첫 번째는 SpringMVC의 기본 의존성이고, 두 번째는 Swagger 의존성이고, 세 번째는 인터페이스 관련 종속성입니다. 이것은 필요하지 않습니다. Springfox와 함께 제공되는 API 인터페이스를 사용하지 않으려면이를 사용할 수 없으며 프로젝트에 맞는 인터페이스 세트를 작성할 수도 있습니다. 이러한 종속성을 추가 한 후 시스템은 Springfox 및 Swagger와 관련된 일부 JAR 패키지를 자동으로 추가합니다. 나는 간단한 모습을 보았고 주로 다음이 있음을 발견했습니다.
Springfox-Swagger2.6.1.jar
Swagger-Nantations-1.5.10.jar
Swagger-Models-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
Guava-17.0.jar
Spring-Plugin-Core-1.2.0. Release.jar
스프링 플러그 메타 데이터 -1.2.0.Release.jar
Spring-Swagger-UI-2.6.1.jar
Jackson-Databind-2.2.3.jar
Jackson-Nantations-2.2.3.jar
위는 Springfox가 시각적으로 필요하다고 생각하는 항아리이며 Springfox가 필요로하는 모든 항아리를 완전히 설명하지는 않습니다. 위의 항아리에서, 우리는 Swagger에 의존하는 것 외에도 Pringfox는 Guava, Spring-Plug, Jackson 및 기타 의존성이 필요하다는 것을 알 수 있습니다 (Jackson은 JSON을 생성하는 데 필요한 JAR 패키지입니다.이 종속성이 프로젝트 자체에 추가되지 않으면 Swagger를 통합하려면이 의존성을 추가해야합니다).
Springfox의 간단한 사용
Springfox의 기본 구성 만 사용하는 경우 SpringMVC와 통합하는 것은 매우 간단합니다. 다음 코드와 유사한 수업을 작성하여 프로젝트에 넣으십시오. 코드는 다음과 같습니다.
@configuration@enablewebmvc@enableswagger2publicclass apiconfig {}위는 빈 Java 클래스 파일이며 클래스 이름은 마음대로 지정할 수 있지만 @configuration, @enablewebmvc 및 @onableswagger2로 표시된 세 가지 주석이 추가되어야합니다. 이로 인해 SpringMVC 및 Springfox의 기본 통합이 완료됩니다. 세 가지 주석을 사용하면 프로젝트가 시작된 후 다음과 유사한 주소를 직접 사용하여 API 목록을 볼 수 있습니다 : http://127.0.0.1:8080/jaddemo/swagger-ui.html
이것은 실제로 매우 마법의 효과입니다. 세 가지 간단한 주석으로 시스템은 프로젝트의 모든 컨트롤러 클래스의 모든 API를 자동으로 표시합니다. 이제이 구성 클래스부터 시작하여 원칙을 단순히 분석하겠습니다. 이 클래스에는 코드가 없으며 세 주석이 중요한 역할을하는 것이 분명합니다. 그 중 @configuration 주석은 이미 스프링 프레임 워크에서 사용할 수 있습니다. @Component 메타 주석으로 식별 된 주석입니다. 따라서이 주석으로 스프링은 클래스를 콩에 자동으로 인스턴스화하여 스프링 컨텍스트에 등록합니다. 따라서 두 번째 주석 @enablewebmvc는 srpingmvc가 활성화되었음을 의미합니다. 이 클립스 에서이 주석을 클릭하여 간단히 살펴보십시오. 메타 주석 @Import (위임장을 위임하는 Webmvcconfiguration.class)를 통해 유형의 위임장 위임장을 스프링 컨텍스트에 넣는 것입니다. 이 클래스의 목적은 Spragger에게 SpringMVC 구성을 제공하는 것입니다. 세 번째 주석 : @enablebsger2. 당신은 이름을 생각할 수 있습니다. Swagger 2를 통합하는 데 사용됩니다. 메타 주석을 통해 @import ({swagger2documentationconfiguration.class})를 통해 Swagger2documentationConfiguration 유형 구성 Bean을 도입했습니다. 이것은 Swagger의 핵심 구성입니다. 내부의 코드는 다음과 같습니다.
@configuration@import ({springfoxwebmvcconfiguration.class, swaggercommonconfiguration.class})@componentscan (basepackages = { "springfox.documentation.swagger2.readers.parameter", "springfox.documentation.swagger2.web", "springfox.documentation.swagger2.mappers"}) publicclassswagger2documentationconfiguration {@bean public jacksonmoduleregistrar swagger2module () {returnnewswagger2jacksonModule (); }}이 클래스 헤더는 일부 주석을 사용한 다음 Springfoxwebmvcconfiguration 클래스 및 SwaggerCommonConconfiguration 클래스를 소개하고 Springfox를 자동으로 스캔합니다. 여기에서 내가 가장 관심이있는 것은 Springfoxwebmvcconfiguration 클래스입니다. 이 클래스는 Springfox 통합 MVC의 핵심 구성이어야한다고 생각합니다. 클릭하고 다음 코드를보십시오.
@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"}@enablepluginregistries ({ DocumentationPlugin.class, ApilistingBuilderPlugin.class, OperationBuilderPlugin.class, ParameterBuilderPlugin.class, ExpdeCeparameterBuilderPlugin.class, ResourceGroupingStrategy.class, OperationModelsProviderPlugin.class, defaultsprovidergin.class, Class, Clasclass. PathDecorator.class}) publicclassspringfoxwebmvcconfiguration {}이 클래스의 다음 코드는 @bean 주석을 통해 새로운 콩을 추가하는 것 이상입니다. 나는 그것에 관심이 없습니다. 내가 가장 관심있는 것은 @enablepluginregistries를 통해 머리에 추가 된 것입니다. Springfox는 Swagger를 통합하기위한 스프링 플러그 메커니즘을 기반으로합니다. 스프링 플러그는 어떻게 구현됩니까? 아직 스프링 플러그의 원리를 연구 할 시간이 없습니다. 그러나 아래에서는 Swagger의 기능을 확장하기 위해 플러그 플러그인을 작성한다고 언급 할 것입니다. @enablepluginregistries를 통해 위에 추가 된 플러그는 아직 사용할 수 없습니다. 내가 본 코드에는 주로 ApilistingBuilderPlugin.class, OperationBuilderPlugin.class, ParameterBuilderPlugin.class, expdeparameterBuilderPlugin.class, ExpdeparameterBuilderPlugin.class, class, class, class, class가 포함됩니다.
최초의 ApilistingBuilderPlugin은 두 개의 구현 클래스, 즉 apilistingReader와 SwaggerApilistingReader가 있습니다. 그 중에서도 아모리스트 리더는 컨트롤러 유형에 따라 API 목록을 자동으로 생성하며 SwaggerApilistingReader는 @API 주석으로 식별 된 클래스에 따라 API 목록을 생성합니다. OperationBuilderPlugin 플러그인은 특정 API 문서를 생성하는 데 사용됩니다. 이 유형의 플러그인에는 많은 구현 클래스가 있습니다. 그들은 각각 노동을 나누고 자신의 일을합니다. 세부 사항을주의 깊게 보지 않았지만 구현 클래스 중 하나 인 OperationParameterReader에만 초점을 맞췄습니다. 이 클래스는 API 매개 변수를 읽는 데 사용되는 플러그인입니다. ModelAttributeParameterExpander 도구 클래스에 의존합니다.이 도구 클래스는 컨트롤러의 인터페이스 메소드 파라미터에서 비소 유형의 명령 객체를 자동으로 구문 분석하여 모든 속성을 포함하는 매개 변수 목록을 얻을 수 있습니다 (아래에 소개되는 재귀를 유발할 수있는 PIT가 있습니다). ExpdedParameterBuilderPlugin 플러그인은 주로이 매개 변수의 데이터 유형을 결정 하고이 인터페이스에 필요한 매개 변수인지 여부와 같은 인터페이스 매개 변수의 일부 기능을 확장하는 데 사용됩니다. 시스템이 시작되면 조정되고 일부는 인터페이스 목록을 스캔하는 데 사용되며 일부는 인터페이스 매개 변수 등을 읽는 데 사용됩니다. 공통 목적은 시스템의 모든 API 인터페이스를 스캔하여 사용자가 볼 수 있도록 캐시하는 것입니다. 그렇다면이 일련의 테이블 플러그가 어떻게 조정되고 실행 입구는 어디에 있습니까?
위의 SpringFoxWebMVCConfiguration 클래스의 코드 헤더에서 ComponentsCan 주석 내용에주의를 기울였습니다. 이 주석에서는 springfox.documentation.spring.web.plugins라는 패키지가 스캔됩니다. 이 패키지는 Springfox-Spring-Web-2.6.1.jar에서 찾을 수 있습니다. 이 패키지에는 두 가지 매우 핵심 클래스, 즉 DocumentationPluginsManager와 DocumentationAtionPluginsBootstrapper가 있음을 발견했습니다. 첫 번째 DocumentationPluginsManager의 경우 인터페이스를 구현하지 않는 Bean이지만 PluginRegistry 유형의 많은 속성이 있으며 @autowired 주석을 통해 속성 값에 주입됩니다. 클래스 이름을 결합하여 모든 플러그를 관리하는 관리자라고 생각하기 쉽습니다. ComponentsCan 주석의 구성으로 인해 이해하기 쉽습니다. 모든 플러그 인스턴스는 스프링으로 Bean에 인스턴스화 된 다음이 DocumentationPluginsManager 인스턴스에 주입하여 균일하게 관리됩니다. 이 패키지 DocumentationPluginsbootstrapper의 또 다른 중요한 클래스는 이름을 보면 플러그의 시작 클래스 일 수 있습니다. 구체적인 내용을 클릭하고 살펴보면 실제로 @Component로 식별 된 구성 요소임을 알게되며, 구조 방법은 방금 설명한 DocumentationPluginsManager 인스턴스를 주입하며 가장 중요한 것은 SmartLifeCycle 인터페이스를 구현한다는 것입니다. 스프링 콩의 수명주기를 아는 사람은이 구성 요소가 콩으로 인스턴스화되고 SRPing 컨텍스트에서 관리되면 start () 메소드가 자동으로 호출된다는 것을 알고 있습니다. START ()를 클릭하여 코드를 보면 코드 스캔 서류 라인이 있음을 알 수 있습니다 (buildContext (각)); API 문서를 스캔하는 데 사용됩니다. 이 메소드의 코드를 더 추적하면이 메소드가 결국 DocumentationPluginsManager 속성을 사용하여 모든 플러그를 함께 조정하여 전체 시스템을 스캔하고 API 문서를 생성 할 수 있습니다. 스캔 결과는 DocumentationCache 클래스의지도 속성에 캐시됩니다.
위는 Srpingmvc의 일반적인 원칙입니다. 주로 Enableswagger2 주석을 통해 일련의 콩을 SRPing 컨텍스트에 주입하고 시스템이 시작될 때 시스템 컨트롤러 클래스를 자동으로 스캔하고 해당 API 정보를 생성하고 캐시합니다. 또한 @Controller 주석에 의해 식별 된 일부 컨트롤러 클래스를 API 목록에 액세스하기 위해 UI 모듈의 항목으로 입력합니다. 예를 들어, Springfox-Swagger2.6.1.jar 패키지의 Swagger2Controller 클래스. 이 컨트롤러는 UI 모듈에서 API 목록에 액세스하는 데 사용되는 인터페이스 주소입니다. API 목록을 보려면 주소 http://127.0.0.1:8080/jaddemo/swagger-ui.html을 방문하면 브라우저를 통해 API 정보 (JSON Format)를 비동기로 얻을 수 있음을 알 수 있습니다. http://127.0.0.1:8080/jaddemo/v2/api-docs?group=sysgroup 및 인터페이스에 표시합니다. 이 주소의 배경에 해당하는 컨트롤러 항목은 위의 Swagger2Controller 클래스입니다. 요청을받은 후이 클래스는 JSON 문자열 리턴을 생성하기 위해 미리 초기화 된 캐시에서 API 정보를 직접 가져옵니다.
Springfox의 원리를 이해 한 후 Springfox를 사용하는 동안 내가 어떤 함정에 직면했는지 살펴 보겠습니다.
Springfox의 첫 번째 큰 구덩이 : 구성 클래스에서 생성 된 Bean은 Spring MVC와 동일한 컨텍스트를 공유해야합니다.
위에서 설명한 것처럼 SpringMVC 프로젝트에서 Springfox를 통합하는 것은 프로젝트의 비즈니스 코드없이 다음과 같이 간단한 구성 클래스를 작성하는 것입니다.
@configuration@enablewebmvc@enableswagger2publicclass apiconfig {}@Configuration 주석 때문에 스프링은 자동으로 콩에 인스턴스화하여 컨텍스트에 주입합니다. 그러나 주목할만한 한 가지 함정은이 콩이 스프링 MVC와 같은 맥락에 있어야한다는 것입니다. 이해하는 방법? 실제 스프링 MVC 프로젝트에는 일반적으로 두 가지 컨텍스트가 있으며, 하나는 컨텍스트를 따르고 다른 하나는 스프링 MVC입니다 (컨텍스트를 따르는 하위 텍스트입니다). 컨텍스트는 org.springframework.web.context.request.requestContextListener 리스너입니다. 로드 된 컨텍스트는 일반적으로 Spring-Contet.xml이라는 구성 파일로 작성됩니다. 여기의 콩은 결국 상황에 맞게 초기화됩니다. 주로 시스템의 서비스, DAO 및 기타 Bean 및 데이터 소스, 사물 등이 포함됩니다. 또 다른 컨텍스트는 Spring MVC입니다. org.springframework.web.servlet.dispatcherservlet web.xml의 Spring MVC와 관련된 Spring MVC를 통해로드됩니다. 일반적으로 spring-mvc.xml이라는 구성 파일이 있습니다. APICONFIG 클래스를 작성할 때 @Configuration 주석으로로드하기로 결정한 경우이 클래스의 경로가 SpringMVC의 구성 요소 스캔 구성의 기본 패키지 범위 내에 있는지 확인해야합니다. apiconfig가 스프링에 의해로드되면 일련의 콩이 주입되기 때문입니다. 이 콩에서는 모든 컨트롤러 클래스를 자동으로 스캔하기 위해 일부 콩은 SpringMVC의 일부 콩에 의존해야합니다. 프로젝트가 컨텍스트의 하위 텍스트로서 srpingmvc의 컨텍스트를 컨텍스트와 분리하는 경우. 우연히이 apiconfig 유형 Bean을 루트 컨텍스트에 스프링 MVC 컨텍스트에 구성 클래스가 없기 때문에 이전 텍스트와 함께로드하십시오.
실제로 Swagger의 API 기능이 생산 프로젝트의 선택 사항이라고 생각하기 때문에 @Configuration 주석을 통해 Swagger를 구성하는 데 동의하지 않습니다. 당사의 Swagger는 종종 프로젝트 프론트 엔드 팀 개발 또는 인터페이스를 통합하기 위해 환경을 테스트하는 데 사용됩니다. 시스템이 온라인 상태 인 후에는 이러한 API 목록이 생산 시스템에 숨겨져있을 가능성이 높습니다. 그러나 구성이 @Configuration 주석을 통해 Java 코드로 작성된 경우 온라인에 갈 때이 기능을 제거하려면 당황스러워 Java 코드를 수정하여 재 컴파일해야합니다. 이를 기반으로 스프링으로 가장 기존의 XML 파일을 구성하는 메소드를 권장합니다. 구체적인 방법은 @Configuration 주석을 제거한 다음 <bean/>과 유사한 Bean 구성을 스프링 XML 구성 파일에 씁니다. 루트 컨텍스트가 MVC 컨텍스트와 분리되는 프로젝트에서는 Spring-MVC.xml로 직접 구성되어 SpringMVC 컨텍스트와 동일한 컨텍스트에 있어야합니다.
Springfox의 두 번째로 큰 구덩이 : 컨트롤러 클래스의 매개 변수는 무한 재귀를 방지하기 위해주의를 기울입니다.
Spring MVC에는 강력한 매개 변수 바인딩 메커니즘이 있으며, 이는 요청 매개 변수를 사용자 정의 명령 개체에 자동으로 바인딩 할 수 있습니다. 따라서 게으르기 위해 많은 개발자가 컨트롤러를 작성할 때 엔티티 객체를 컨트롤러 메소드의 매개 변수로 직접 사용합니다. 예를 들어 다음 예제 코드 :
@requestmapping (value = "update") 공개 문자열 업데이트 (menuvoMenuvo, 모델 모델) {}이것은 대부분의 프로그래머가 엔티티를 수정하기 위해 컨트롤러로 작성하는 코드입니다. Swagger와 통합 할 때 여기에는 큰 구덩이가 있습니다. Menuvo의 모든 속성이 기본 유형이라면 괜찮습니다. 잘못된 것은 없습니다. 그러나이 클래스에 다른 사용자 정의 유형 속성이 있고이 속성이 직접 또는 간접적으로 자체 유형의 속성이 존재하는 경우 문제가 있습니다. 예를 들어 : Menuvo 클래스가 메뉴 클래스 인 경우 부모 메뉴를 나타내는 Menuvo 유형의 속성 부모도 포함됩니다. 이러한 방식으로 Swagger 모듈은 API를로드 할 수 없기 때문에 시스템이 시작될 때 오류를 직접보고합니다. 오류의 이유는이 메소드를로드 할 때 업데이트 메소드의 매개 변수가 구문 분석되기 때문입니다. 매개 변수 Menuvo가 간단한 유형이 아닌 경우, 모든 클래스 속성은 자동으로 재귀 적으로 해석됩니다. 이것은 무한 재귀의 죽은 루프에 쉽게 빠지게 할 수있게합니다.
이 문제를 해결하기 위해 OperationParametErreader 플러그인 구현 클래스와 ModelAttributeParametereXpander 도구 클래스를 작성했습니다. 구성을 통해 원래 두 클래스의 srpingfox 클래스를 대체하고, 매개 변수 분석을 열처럼 구문 분석하는 논리를 대체하며, 무한 재귀를 피합니다. 물론 이것은 소스 코드 레벨을 수정하는 방법과 동일합니다. 아직이 문제에 대한 더 완벽한 솔루션을 찾지 못했기 때문에 스프링 폭스 스와거를 사용할 때이 무한 재귀를 피하는 것이 좋습니다. 결국 이것은 SpringMVC 명령 개체의 사양을 준수하지 않습니다. SpringMVC 매개 변수가있는 명령 개체는 바람직하게는 간단한 기본 유형 속성입니다.
Springfox의 세 번째 주요 Pit : API 그룹화 관련, 도켓 인스턴스를 잠재적으로로드 할 수 없습니다.
Springfox는 모든 API를 기본적으로 그룹으로 나눕니다. http://127.0.0.1:8080/jaddemo/swagger-ui.html과 유사한 주소를 통해 액세스하면 모든 API 목록이 같은 페이지에로드됩니다. 이런 식으로 시스템이 조금 더 크고 API가 조금 더 있으면 페이지가 위조되므로 API를 그룹화해야합니다. API 그룹화는 APICONF 구성 파일의 @Bean 주석에 의해 정의됩니다. 인터넷의 일반적인 구성은 다음과 같습니다.
@enablewebmvc@enablebsger2publicclass apiconfig {@bean public docket customDocket () {return newDocket (documentationType.wagger_2) .apiinfo (apiinfo ()); }}위의 코드에서는 @bean을 통해 도켓이 주입됩니다. 이 구성은 필요하지 않습니다. 이 구성을 사용할 수 없으면 프레임 워크는 자체적으로 기본 도켓 인스턴스를 생성합니다. 이 도켓 인스턴스의 목적은 API 버전, 저자 등과 같은 기본 정보와 같은 기본 정보의 공개 정보를 지정하고 (API 주소 또는 주석에 의해 필터링되는지)를 지정하는 것입니다.
다음 코드와 같은 여러 개의 도켓 인스턴스가있을 수 있습니다.
@enableWebmvc@enableSwagger2PublicClass apiconfig {@bean public docket customDocket1 () {return newDocket (d } @bean public docket customDocket2 () {return newDocket (hoc }}프로젝트에서 다중 도켓 인스턴스가 구성되면 API를 그룹화 할 수 있습니다. 예를 들어 위의 코드는 API를 두 그룹으로 나눕니다. 이 경우 각 그룹에는 위 코드에서 "Apigroup1"및 "Apigroup2"와 같은 다른 이름이 할당되어야합니다. 각 그룹은 경로를 사용하여 개미 스타일 주소 표현식을 통해 어떤 API를 관리 할 그룹을 지정할 수 있습니다. 예를 들어, 위의 구성에서 첫 번째 관리 주소 그룹은 /sys /의 시작이있는 API입니다. /shop /의 시작을 가진 두 번째 관리 API 그룹. 물론 클래스 주석, 메소드 주석, 주소 정규 표현식 등과 같은 다른 필터링 방법이 많이 있습니다. 그룹화 후 API 목록 인터페이스의 오른쪽 상단 코너에서 드롭 다운 옵션에서 다른 API 그룹을 선택할 수 있습니다. 이것은 프로젝트의 API 목록을 다른 페이지로 분산시킵니다. 이는 페이지가 너무 많은 API를로드해야하기 때문에 죽은 척하지 않고 관리를 용이하게합니다.
그러나 @Configuration을 사용하는 것과 같이 @Bean을 사용하여 Docket 인스턴스를 Group API로 구성하는 데 동의하지 않습니다. 이로 인해 코드는 또한 사형으로 기록됩니다. 따라서 이러한 유사한 기능을 구현하려면 XML 파일에서 자신의 도켓 인스턴스를 구성하는 것이 좋습니다. 물론, 도켓의 많은 속성을 고려할 때 콩을 직접 구성하는 것이 더 번거 롭습니다. 도켓 직접 공장 비를 작성한 다음 XML 파일에서 FactoryBean을 구성 할 수 있습니다. 그러나 도켓을 XML로 구성 할 때. 또 다른 큰 구덩이, 즉 콩의 스프링의 적재 방법은 기본적으로 게으른 적재입니다. XML에서 이러한 도켓 인스턴스 Bean을 직접 구성한 후. 효과가 없으며 페이지의 왼쪽 상단에있는 드롭 다운 목록에 그룹화 항목이 없습니다.
이 문제는 몇 시간 동안 나를 괴롭 혔습니다. 나중에 경험을 바탕으로 스프링 콩이 기본적으로 게으른 로딩이기 때문에이 도켓 인스턴스가 스프링 컨텍스트에로드되지 않았기 때문일 수 있습니다. 결과적으로 내 추측이 맞습니다. 이것이 Springfox의 버그인지 또는 Docket 구성을 원래 Java 코드에서 XML 구성 파일로 이동하지 않아야하는지 모르겠습니다.
Springfox의 다른 함정 : Springfox에는 다른 함정이 있습니다. 예를 들어, @apioperation 주석에서 httpmethod 속성이 특정 get 또는 post 메소드로 지정되지 않으면 Get, post, delete, put과 같은 모든 메소드가 API 목록에 나열되어 API 목록이 너무 많이 복제되도록합니다. 또한 테스트 중에 로그인 권한 문제 등을 만났습니다. 공간이 제한되어 있기 때문에 해결하기 쉬운 작은 구덩이 더미가 많이 말하지 않을 것입니다. @api, @apioperation 및 @apiparam과 같은 주석의 사용도 있습니다. 이 온라인에서 많은 문서를 반복하지 않을 것입니다.
위는이 기사의 모든 내용입니다. 모든 사람의 학습에 도움이되기를 바랍니다. 모든 사람이 wulin.com을 더 지원하기를 바랍니다.