[feat] 사용 변경 신청 및 관리자 승인/거절, 그룹 생성

[saokiritoni]

🌱 관련 이슈

• close : [ feat ] 서버 사용 신청 수정 #112
• related: [ feat ] 그룹 관련 API 연결 #126

🌱 작업 사항

서버 신청(Request) 변경 요청 (ChangeRequest) 관련 작업

• 사용자가 변경 요청을 할 수 있다. (저장공간 크기, 만료기한, 사용자가 속한 그룹, 리소스 그룹, 도커 이미지)
• 관리자가 변경 승인을 할 수 있다.
• 관리자가 변경 거절을 할 수 있다.

컨트롤러 역할 분리 (AdminRequestController, AdminRequestChangeController)

• 기존에는 모든 관리자 관련 요청이 하나의 컨트롤러에 몰려 있어서, 특정 도메인에 대한 책임이 불명확했습니다.
• AdminRequestController: 신규 서버 사용 신청 조회, 승인, 거질 등 Request'기능만 담당하도록 분리했습니다.
• AdminRequestChangeController: 사용자가 제출한 변경 요청 조회, 승인, 거절 등 ChangeRequest기능만 담당하도록 분리했습니다.

API URI 및 용어 통일

• 기존에는 approve와 approveModification처럼 기능에 따라 메서드 명, URI 경로가 달랐고, 거절 기능의 경우 reject와 deny가 혼용되어 있었습니다.
• /api/admin/request는 신규 요청 관련 기능을, /api/admin/requests/change는 변경 관련 기능을 다루도록 보다 명확하게 경로를 분리했습니다.
• '거절'의 개념은 reject로 통일했습니다. 비즈니스 메서드명도 reject + N 형태로 통일했습니다.

ubuntu 그룹 생성 API 연결

• Spring의 client에서는 gid를 직접 받지 않고, 내부적으로 id값을 할당하여 다시 Config 서버에 요청을 보내는 것이 핵심입니다.
• 이를 위해서 GroupService 내부 DTO를 생성하였습니다. 서비스 코드와 분리할 지에 대한 고려가 필요하지만, 지금은 서비스 코드가 길지 않아 한 클래스에 작성했습니다.
• ubuntuUsername은 입력을 받을 수도, 받지 않을 수도 있습니다.

짜잘한 수정

• 컨트롤러 공통 응답으로 맞춰 수정했습니다.
• API 문서를 작성했습니다.
• DTO validation을 강화했습니다.
• enum의 이름에 ID가 붙은 게 오히려 혼란스러워서 같은 형태로 통일했습니다.

엔티티 메서드 수정

• update()로 전체 필드를 통으로 처리하는 것에서, 각 필드를 update하는 것으로 수정했습니다.
• 기존의 update()는 volumeSizeGiB와 expiresAt만 처리하도록 고정되어 있었습니다. 만약에 새로운 변경 요구사항이 들어오면 이 메서드를 계속해서 수정해야 하는 문제가 발생합니다.
• 하지만 각 필드에 대한 updateVolumeSize()등 setter 역할 메서드를 두면, 서비스 레이어의 switch-case문만 수정해주면 되기 때문에 변경 사항의 폭이 줄어들 것이라고 생각했습니다.
• 하지만 그룹 관련 Update는 로직이 너무 길고 복잡해서 서비스 레이어에 넘겼습니다. (기존 그룹 초기화 -> 새로운 그룹 조회 -> 유효성 검증 -> 새로운 그룹 할당) 특히 Request, RequestGroup, Group, ChangeRequest, Group ...이 엔티티 전체에 영향을 주는 메서드가 될 거라서, 한 엔티티 안에 넣기는 SRP에 맞지 않다고 생각했습니다. 특히 Request에 넣으면, 이 엔티티가 GroupRepository에 의존해야 하는데 도메인 엔티티가 인프라 레이어에 의존하게 되어 순수성을 잃어버릴 수밖에 없습니다.

🌱 참고 사항

• 다른 get에서 그룹 정보 반환도 필요할 것 같으니 추가 필요!
• 서비스 코드도 공통 부분을 묶어서 처리하는 리팩토링이 필요할 거 같습니다. 특히 WebClient 부분..
• 이제 프론트도 작업 바로 들어가면 될 거 같습니다!!
• 내 Request의 ubuntuUsername을 조회하는 API를 추가하면 좋을 거 같습니다.

[kwdahun]

This pull request refactors and expands the admin request management APIs, splitting change request handling into a dedicated controller and interface, improving API documentation, and standardizing success responses. It also enhances DTOs with Swagger annotations for better API documentation and clarifies enum values for change types.

API Structure and Documentation Improvements

• Split change request handling from AdminRequestController into a new AdminRequestChangeController and corresponding AdminRequestChangeApi interface, providing dedicated endpoints for change request listing, approval, and rejection. [1] [2]
• Updated AdminRequestApi to use SuccessResponse wrappers for all endpoints, improved Swagger documentation, and removed change request endpoints from this interface.
• Added detailed Swagger annotations to DTOs, including ApproveModificationDTO, RejectModificationDTO, and ModifyRequestDTO, enhancing API schema clarity and documentation. [1] [2] [3] [4]

Controller and Endpoint Changes

• Refactored AdminRequestController to remove change request approval and listing, and standardized all responses to use SuccessResponse. Endpoints for resource usage and container info were also updated to use this response format.
• Added descriptive comments to user-facing endpoints in RequestController for better maintainability. [1] [2] [3]

Domain and DTO Enhancements

• Clarified the ChangeType enum values to be more descriptive and aligned with business logic (e.g., GROUP, RESOURCE_GROUP, CONTAINER_IMAGE).
• Updated GroupRepository to add a new method for finding a group by its Ubuntu GID, improving query capabilities.