잉여개발자

배경 API 설계시 일부 기업이나 방법론 중 모든 상태 코드를 200으로 처리하는 방법이 종종 거론되곤 한다. 관련 링크 : https://okky.kr/questions/661303 (카더라긴 하지만 댓글에 기타 정보 내용이 있음) 일반적으로 응답 코드는 요청에 대한 상태를 나타내는 HTTP 상태 코드(Status code)와, 에러에 대한 정보를 담은 세부 에러 코드(Error code)로 나뉘며 일반적인 처리는 상태 코드별로 > 세부 에러 코드를 나누는 것이 일반적이다. 위에 말한 방법은 상태 코드를 통일하고 > 세부 에러 코드로 통합 하는 것 이다. 모든 상태코드를 200으로 고정하여 처리 하는 경우 주된 목적 : HTTP Status Code가 노출 될 시 보안에 위험이 있을 수 있음 (ex...

토스페이먼츠 정책 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바이트) 으로 변환..

API를 설계하며 고민 한 것들을 적어 놓는 공간. 백엔드가 고려해야 될 것 들 Restful 한 API 설계를 했는지 문서화가 좋은지 사용법이 명확한지 (외부 SDK로 배포하더라도 괜찮은 정도의 퀄인지 생각해보기) API가 UI에 종속되지 않아야 한다 -> UI가 바뀌더라도, 사용 할수 있는가 백엔드의 1차적인 유저는 프론트라는 점 아 이사람 api 잘 짜주던데~ 좋은 API 문서 예시 네이버 NCloud (링크) 상태코드를 존중한 Restful 한 작성 NHN (링크) 모든 API를 200으로 처리함 (링크) 성공과 실패에 대한 Redoc 활용 좋은 예시 Redoc에서 상태코드를 지켜서 문서화 (링크) Permission 범위 작은 범위의 permission 체크 (공통 레벨) 해당 모델에 대한 체크..