2022-05-17-TIL
Today I Learned
Boolean Field in API
API 응답이나 요청에 isActive: true 같은 boolean 필드를 두면 처음에는 간단하다. 문제는 상태가 둘에서 셋으로 늘어날 때다. 예를 들어 isActive만 있던 회원에 “휴면”이나 “정지” 상태가 추가되면, boolean 필드를 하나 더 만들거나(isSuspended) 의미를 억지로 겹쳐야 한다. 필드가 늘면 isActive: true, isSuspended: true처럼 말이 안 되는 조합도 표현할 수 있게 된다.
그래서 상태를 나타내는 값은 처음부터 enum으로 두는 편이 낫다. Google의 API 설계 지침 AIP-216은 상태를 전달해야 하는 리소스는 State라는 이름의 enum을 쓰라고 권한다. 새 상태가 생겨도 enum 값을 하나 추가하면 되고, 클라이언트는 모르는 값을 받았을 때의 처리만 준비하면 된다. 반대로 정말 두 값만 있을 수밖에 없는 속성(예: 필수 여부)이라면 boolean이 맞고, 같은 Google 지침의 AIP-140은 이때 is_ 접두사를 붙이지 말고 required, disabled처럼 쓰라고 한다.
- https://medium.com/geekculture/why-you-shouldnt-use-booleans-in-rest-apis-2747b187876c
MyBatis Paging with PageHelper
MyBatis는 SQL을 직접 쓰는 방식이라 페이징도 LIMIT, OFFSET과 전체 개수를 세는 COUNT 쿼리를 매번 직접 작성해야 한다. PageHelper는 이를 대신해 주는 MyBatis 플러그인(PageInterceptor)이다.
사용법 문서에 따르면 페이징할 MyBatis 조회 메서드 바로 앞에서 PageHelper.startPage를 호출하면, 그 직후에 실행되는 첫 번째 MyBatis 조회만 페이징된다.
1
2
3
PageHelper.startPage(1, 10);
List<User> users = userMapper.selectAll(); // 이 조회만 페이징된다
PageInfo<User> page = new PageInfo<>(users);
startPage와 조회 사이에 다른 조회가 끼거나, startPage를 불러 놓고 조회가 실행되지 않으면 엉뚱한 쿼리가 페이징될 수 있다. 문서가 “안전한 호출” 방법과 이를 찾아내는 debug 옵션을 따로 설명하는 이유다. 그래서 startPage와 조회는 항상 바로 붙여 쓴다.
- https://oingdaddy.tistory.com/329
MyBatis vs Spring JDBC
둘 다 JPA처럼 객체와 테이블을 자동으로 매핑하지 않고 SQL을 직접 쓰는 방식이다. 차이는 SQL을 어디에 두고 결과를 어떻게 옮기느냐다.
- MyBatis는 사용자 정의 SQL, 저장 프로시저, 고급 매핑을 지원하는 퍼시스턴스 프레임워크다. JDBC 코드와 파라미터 설정, 결과 조회 코드를 거의 모두 없애 주고, XML이나 애너테이션으로 SQL과 결과 매핑을 설정한다. 조건에 따라 SQL을 바꾸는 동적 SQL(
<if>,<foreach>)이 강점이다. - Spring JDBC의
JdbcTemplate은 커넥션 생성과 해제 같은 자원 관리와 JDBC의 기본 흐름을 처리하고, 애플리케이션은 SQL을 제공하고 결과를 꺼내는 일만 하면 된다. SQL은 자바 코드 안에 두고, 결과는RowMapper로 직접 객체에 옮긴다.
SQL이 많고 복잡하며 동적 조건이 많다면 MyBatis가, 쿼리가 몇 개 안 되고 의존성을 늘리고 싶지 않다면 JdbcTemplate이 가볍다.
- https://hello-bryan.tistory.com/335
REST API Response를 권한에 따라 다르게 내려주는 방법
- API URL 엔드포인트를 분리한다. 가장 깔끔하다.
- 컨트롤러 계층에서 권한을 검사한 후 권한에 맞는 서비스 메서드를 호출한다. API를 간결하게 유지하면서 BE 코드만 복잡해진다.
- 서비스에서 사용자 권한을 검사한 후 권한에 맞는 레파지토리 메서드를 호출한다. 메서드 중복을 최대한 줄일 수 있다.
1번은 /admin/users/{id}와 /users/{id}처럼 경로가 나뉘므로, 경로 단위로 접근 제어를 걸 수 있고 응답 DTO도 각각 명확하다. 대신 비슷한 API가 둘씩 생긴다. 2번과 3번은 같은 URL이 요청한 사람에 따라 다른 모양의 응답을 돌려주므로, API 문서에 어떤 권한에서 어떤 필드가 오는지 분명히 적어 두어야 클라이언트가 헷갈리지 않는다. 어느 방법이든 권한 검사를 빠뜨리면 정보가 새므로, 응답에서 필드를 빼는 것만으로 접근 제어를 대신하지 않도록 주의한다.
- https://okky.kr/article/1118179
AMQP
AMQP(Advanced Message Queuing Protocol)는 메시징 미들웨어 사이의 상호 운용을 위한 개방형 표준 프로토콜이다. AMQP 공식 사이트는 모든 메시징 미들웨어 간 상호 운용을 위한 표준 프로토콜이 되는 것을 목표로 내세우고, AMQP 1.0은 OASIS 표준을 거쳐 국제 표준 ISO/IEC 19464가 되었다.
주의할 점은 AMQP에 여러 버전이 있다는 것이다. RabbitMQ 문서에서 설명하는 exchange, queue, binding 모델은 AMQP 0-9-1의 모델이다. RabbitMQ의 AMQP 1.0 문서에 따르면 RabbitMQ는 4.0부터 AMQP 1.0을 플러그인 없이 기본 지원하고, 같은 5672 포트에서 클라이언트가 처음 보내는 프로토콜 헤더로 1.0과 0-9-1 중 무엇을 쓸지 정한다. 그래서 “AMQP를 지원한다”는 말을 보면 어느 버전인지 확인해야 한다.
- https://www.amqp.org/
댓글
아직 댓글이 없습니다