전문통신을 Restful api로 바꾸고 싶습니다

Question

오프라인 기반의 통신 서버에서 복사를 해온(당시 예산없어서)
모바일 앱을 위한 api서버로 이용중입니다

메세지 타입 4자리 번호로 구분하여
주문과 결제 등 40가지 서비스에 대해
4~6개 컨트롤러 내에서 분기해서 처리하고 있습니다

내부에 보다보니 하나의 메소드 내 Case문이 40여개나 되고 if문이 수십분기입니다

오라클 19c사용중이고 프로시져로 덕지덕지 크게크게 사용중이어서 영수증만드는 string 연산도 다중 프로시져로 생성중에 있습니다. 프로시져도 was에서 연산하게 해버리고 싶네요

전문통신을 기반으로 사용하던 통신서버를 복제한 탓인지
메세지타입으로만 로직흐름을 보자니 공통 클래스에 전무 묶여있어 파악이 힘드네요

이런형태가 일반적인건지 모르겠습니다

하나의 서비스는 하나의 컨트롤러 내 메소드외 1대1 매핑이 되도록 처리한다 라는 생각을 가지고 있는데 이 시스템을 개선해야한다면 어떻게 바꿔나가야할지 문의드립니다

ex) 팀장설득 방법(돈들이게 하는방법-차세대, 돈없어도 부분부분 바꾸게 허가받는방법) 등

ps. 팀장님은 코드 잘 모르심. 아이티출신이지만 기획에 치중된 업무를 오랫동안 해오심

ㄱㅎㅁ · Answer

기술부채 및 유지보수, 향후 인력수급,읽기쉬운 클린코드
이 3가지 관점에서 설득하시고, 차세대보다는 일부 로직들을 부분씩 띄워내는걸로 설득하는게 윗선까지 가는게 쉬울거 같습니다.

이영준 · Answer

옛날에 c로 socket 통신하는 서버들을 그렇게 만들었져
내부 서버를 띄워서 분리시키는 방법을 사용했죠.
가능하다면 rest를 만들어서 작은 메세지 부터 처리를 넘겨보는 것도 방법이겠네영

kevin · Answer

힘내십쇼!!

커리어리 AI 봇 · Answer

전문통신 서버를 RESTful API로 변경하는 것은 좋은 아이디어입니다. RESTful API는 클라이언트와 서버 간의 통신을 위한 일관된 방법을 제공하여 애플리케이션의 유지 보수성과 확장성을 향상시킬 수 있습니다.

기존의 메시지 타입을 사용하여 분기하는 방식에서 개선하기 위해 다음과 같은 접근 방식을 고려해 볼 수 있습니다.

1. 리소스 기반 접근: RESTful API는 리소스 기반 접근 방식을 사용합니다. 따라서 주문, 결제 등과 같은 서비스를 개별 리소스로 정의하고, 각 리소스에 대한 CRUD(Create, Read, Update, Delete) 연산을 수행하는 API 엔드포인트를 제공합니다. 이렇게 하면 각 서비스에 대한 컨트롤러가 독립적으로 존재하게 되어 코드의 가독성과 유지 보수성이 향상됩니다.

2. 각 서비스의 독립성 확보: 각 서비스는 독립된 컨트롤러와 모델로 구성되어야 합니다. 이렇게 하면 코드의 재사용성과 모듈화가 용이해지며, 각 서비스를 독립적으로 수정하거나 추가할 수 있습니다. 이를 통해 각 서비스를 개선하는 데 필요한 작업 범위를 축소할 수 있습니다.

3. 상태를 관리하지 않는 설계: RESTful API는 상태를 관리하지 않는(stateless) 설계 원칙을 따릅니다. 따라서 클라이언트의 상태 정보를 서버에 저장하지 않고, 요청마다 필요한 정보를 전송합니다. 이를 통해 서버의 부하를 줄이고 확장성을 향상시킬 수 있습니다.

4. API 문서화: API의 사용 방법과 응답 형식을 명확히 문서화하여 개발자들이 API를 쉽게 이해하고 사용할 수 있도록 합니다. API 문서화는 Swagger와 같은 도구를 사용하여 자동화할 수 있으며, 이를 통해 개발자 간의 협업과 통신이 원활해집니다.

개선을 위해 팀장을 설득하는 방법은 다양한 요소를 고려해야 합니다. 아래는 몇 가지 아이디어입니다.

1. 비용 효율성: RESTful API로의 전환은 장기적인 관점에서 비용 효율성을 제공할 수 있습니다. 코드의 모듈화 및 재사용, 유지 보수 용이성 등을 강조하여 개발자들의 작업 효율성과 생산성 향상을 설명할 수 있습니다.

2. 확장성: RESTful API는 애플리케이션의 확장성을 향상시킬 수 있는 기반을 제공합니다. 새로운 기능 추가, 서비스 확장, 다양한 클라이언트 플랫폼 지원 등에 대한 유연성을 강조하여 향후 비즈니스 요구에 더 나은 대응을 할 수 있다는 점을 강조할 수 있습니다.

3. 기술적 이점: RESTful API는 기술 생태계에서 널리 사용되는 표준이며, 다양한 개발자 커뮤니티 및 지원 자료가 존재합니다. 이를 통해 개발자들이 보다 쉽게 이해하고 사용할 수 있으며, 새로운 개발자를 채용하거나 향후 유지 보수를 위한 리소스를 찾는 데 도움이 될 수 있습니다.

4. 점진적 개선: 모든 변경을 한 번에 적용하는 대신 점진적으로 개선하는 방법을 제안할 수 있습니다. 예산의 제약으로 인해 전체 시스템을 재작성하기 어려운 상황이라면, 단계적으로 기능을 분리하고 RESTful API를 도입하는 방식을 제안할 수 있습니다. 이렇게 하면 작은 변경으로부터 시작하여 점진적으로 시스템을 개선할 수 있습니다.

위의 아이디어를 사용하여 팀장에게 접근하여 현재 시스템을 개선하기 위해 RESTful API로 전환하는 이점과 비용 효율성에 대해 설명해보세요. 특히 코드의 모듈화와 재사용, 유지 보수 용이성, 확장성, 표준 기술 사용 등을 강조하여 설득할 수 있을 것입니다. 또한 점진적 개선 방법을 제안하여 전체적인 변경을 요구하지 않고 시스템을 개선할 수 있는 방법을 제시해 보세요.