잉여개발자

토스페이먼츠 정책 API 버전 정책 링크 기존 버전을 수정하는 경우 (v1) 새로운 버전을 릴리즈 하는 경우 (v2, v3, v4 .. 등) 엔드 포인트 새로운 API 엔드포인트 추가 기존 API 엔드포인트 제거 파라미터 (요청) API 요청에 새로운 선택 파라미터 추가 API 요청에서 사용하는 필수 파라미터를 선택 파라미터로 변경 API 요청에 새로운 필수 파라미터 추가 API 요청의 선택 파라미터를 필수 파라미터로 변경 응답 API 응답에 새로운 필드 추가 API 응답에 사용되던 필드 삭제 API 응답 nullable 하지 않았던 필드를 nullable 변경 API 응답 필드의 데이터 타입 변경 Enum 새로운 ENUM 추가 같은 의미를 나타내는 ENUM 코드의 변경 (예: 토스결제 → 토스페이) 에..

조회 한 데이터 없음 데이터 조회 요청시, 요청 한 데이터가 없을 경우 다음과 같이 처리 할 수 있다. 1) 200 + 빈 리스트 - 올바른 경로로 호출하여 200 응답, 하지만 데이터는 없으므로 빈 값, 빈 리스트 반환 2) 특정 에러 코드 (ex. 4001, 34011) - 데이터가 없음을 특정 에러로 규정하여 에러 코드로 응답 404 에 대한 이해 사실 조회 데이터가 없음은 404 개념에 해당되는 것 같지만, 클라이언트와 서버는 404 개념에 대해 받아 들이는 것에 차이가 존재한다. 클라이언트 : 잘못된 "경로" 접근 서버 : "리소스" 존재 X 404에 대해 좀더 살펴 보면, 404는 여러 가지 기술적인 이유로 발생할 수 있다. 서버에서 애플리케이션이 일시적으로 비활성화되거나 제거됨 프록시 연결 ..

배경 API 설계시 내려가는 Schema 값이 없을 경우, 다음과 같이 처리 할 수 있다. 1) Null을 그대로 내린다. 2) Null을 정해진 기본값(빈 문자열, 빈 리스트 등)으로 치환해서 내린다. 3) Null이 들어 있는 key를 처음부터 내리지 않는다. 사례 사례 1) 한 API를 여러 경우(화면) 에서 사용하며, 여집합 필드가 존재함 ex) A 화면에서는 해당 API의 a 필드가 사용되지만, B 화면에서는 해당 a 필드가 사용되지 않음. - 여기서 화면별로 API를 처음부터 나누지 않는 이유는, UI 에 종속 되지 않는 API를 설계하기 위함 - B 화면에 대한 요청의 경우 1), 2) 중 선택 가능 사례 2) 동일 화면이지만 시점에 따라, 데이터의 특정 필드가 DB에 입력 된 적이 없는 경..

한 페이지 정보 - API 1개 vs 2개 한 페이지에 정보 내릴 때 몇 개의 API로 내릴 것인가 ex. 유저(A)의 ~ 데이터 (B) 목록 조회 API 1개 유저(A)의 데이터(B)를 묶어서 내림 http 및 db 커넥션 감소, api 수 줄이는게 좋다. API 2개 api는 페이지에 종속되면 안된다. 한 가지 함수는 한 가지 기능만 담당하는 것 처럼, 하나의 API는 하나의 정보만 담당하는 것도 좋다. 재사용성, 유지 보수에 좋다 API 이슈 있을 시 에러가 전파되지 않음 설계시 고민할 부분 API 수를 줄이는 측면에서, 해당 부분이 성능이 그렇게 까지 중요한 부분인가? 예로 관리자 서비스의 페이지 정보라면 성능보단 재사용성, 유지보수에 중점

1. 쿼리 파라미터 값 - 문자 vs 숫자 1) 문자 일 경우 ex) ?filter=inprogress endpoint url은 애초에 드러나는 것이므로 보다 직관적임 숫자 방식에 비해 임의로 데이터를 찔러보기 어려움 (해석이 비교적 어려움) 2) 숫자 일 경우 ex) ?filter=1 문자 방식에 비해 임의로 데이터를 찔러보기 쉬움 (해석이 쉬움) 결론 : 1을 조금 더 선호 2. 쿼리 파라미터 값 - 한글 문자 vs 영어 문자 1) 한글 문자 ex) ?filter=진행중 해당 '진행중'을 URL에 포함하여 요청시 변환 과정을 거침 변환 과정 : Unicode의 값 (ex. U+C21C)을 찾음 UTF-8 인코딩 (ex. 11100011, 10001000, 1011000 - 무조건 3바이트) 으로 변환..

임시 저장 서비스사내에서 임시 저장 서비스를 구현하면서, 어떻게 할 것인가.. 어떤 방법이 좋은가에 대해 고민했던 부분을 공유해보려고 한다. 결과적으로, 설계 당시에 선택한 방법이 가져올 문제점 등에 대해 충분히 고려하지 못해 나중에 수고스러워 지는 부분도 있었던 것도 같고, 다음에 구현하게 될 때 좀더 빠르고 정확하게 할 수 있도록 기록을 남겨 보려 한다. 임시 저장 서비스 기능 요구 사항상태 : 임시 저장, 생성 완료 (발행)임시 저장 데이터 : 생성, 수정, 삭제, 조회 가능완성 데이터 : 생성, 수정, 삭제, 조회 가능데이터 목록 : 임시 저장, 완성 데이터는 같이 조회가능 해야 함중요 : 완성 데이터가 있어도 임시 저장 데이터가 유효 해야 함중요 : 사용자는 하나의 객체에 대해서만 생서/수정 한..

서비스를 개발하면서 들어오는 파라미터에 대해 검증하는 로직을 작성하였고,해당 필드만 검증하거나, 여러 필드를 한번에 검증해야 된다거나 등등의 여러 경우가 있었다.사용한 여러 방법들에 대해 정리해보려고 한다. 기본적으로 Django Ninja의 Schema는 Pydantic의 BaseModel을 wrapping 하여 만들어 졌기에,validation은 BaseModel의 @validator, @root_validator 등의 기호를 사용하여 진행하였다. (pydantic 1.x) 1.  타입 검증 (Type Check Validation)기본적으로 Type에 대한 체크는 Ninja의 Schema에서 선언시 내부적으로 타입을 체크 해준다.만약 유효하지 않은 Type을 보낼시, 422 엔티티 에러가 발생한다...

에러 핸들링 구현기 프로젝트를 진행하며 초기 셋팅시, 에러에 대한 핸들링 처리를 통해 서버에 대한 신뢰도와 안정성을 높이는 작업을 진행하였고, 해당 과정에서 최종 정의한 에러 범위에 대한 정의, 정의 간 고려사항, 처리 방법 등에 대해 정리 해보았다. 에러 핸들링 처리는 목적은 다 똑같지만.. 범위나 방법 등에 대해서는 기업마다 팀마다 다를 것이라고 생각한다. 에러 핸들링 이란? 런타임 과정, 혹은 특정 예외 상황에서 발생하는 에러/비정상적인 상황들 (ValidationError, AuthError, ServiceLogicError 등)에 대해 직접 의도된 동작으로 처리 하는 기술 에러 핸들링의 주요 목표는 다음과 같다. - SW의 비정상적인 종료들로 인한 사용자 경험 저해 방지 - 프로그램에 대한 안정..

Github flow와 Git flow는 Git 기반의 브랜치 전략 워크 플로우 입니다. 개발팀 조직의 규모나 니즈에 맞게, 선택해서 사용 하는 것이 일반적 입니다. Github flow 기본적인 브랜치 전략으로, 단순하고 간결하며, 지속적인 배포에 중점을 둔 워크 플로우 입니다. 주요 브랜치로는 Main 브랜치, Feature 브랜치, State/Production 브랜치 (Optional) 가 있다. 📂 Github Workflow 1) Feature 브랜치에서 기능 개발 2) Feature 브랜치에서 Main 브랜치로 Pull Request 및 Merge 3) Main 브랜치에서 Stage 브랜치나 Production 브랜치로 최종 Merge - 여기서 Stage나 Production 브랜치는, 운..

Jenkins Pipeline Slack Notification 연동 방법 1. Slack에서 Jenkins 앱을 추가로 설치한다. 2. Slack에서 Jenkins Pipeline에 대한 결과 notification을 수신할 채널을 생성한다. (#jenkins_cicd) 아래 3~5 부터는 다음 링크 참조하면 좋음 3. Slack에서 해당 워크 스페이스에 대한 이름과, Integreation Token Credential ID를 확인 한다. 4. Jenkins에서 Slack Notification Plugin을 설치한다. 5. Jenkins System에서 슬랙 관련 정보를 등록한다. 5.1 Workspace : Team Subdomain 값 5.2 Credential : 신규 생성 - kind : s..