REST API 엔드포인트 명명
API 명세서에 엔드포인트를 작성하기 전에 컨벤션을 정하는 과정에서 다른 의견이 나왔고, 더 나은 명명법을 찾아보았다.
REST API 설계에서 엔드포인트는 직관적이고 일관적으로 설계해야한다. 검색된 포스팅에 가장 많이 인용된 글이 있었다. 이 글과 다른 자료를 참고해 정리를 해보면 상황에 따라 관례적으로 사용되는 명명법이 분리되어 있었다.
- 하이픈(-)
프론트엔드와 가까운 영역에서 사용한다. 브라우저와 편집기에서 밑줄(_)은 시각적 신호로 오해되거나 숨겨질 수 있으므로 이를 방지하기 위해 하이픈을 선호한다. - 스네이크 케이스(_)
데이터와 관련된 영역(데이터베이스, JSON)에서는 언더바(_)를 사용한다. - 카멜 케이스
서버에서 보통 사용한다.
팀 활동
1. 도메인 고민
요구사항 분석과 도메인 설계에 시간이 오래 걸리고 있다. 하지만 도메인에 대한 고민이 완성 자체보다 더 값질 수 있다고 생각을 하기 때문에 감안하여 진행기간에서 타협을 해야할 것 같다.
2. API 명세서 작성
엔드포인트 및 요청/응답 샘플 데이터 작성을 진행했다. 제시된 기본적인 틀에서 크게 벗어나지 않으려고 했지만, 가독성을 위해 폼을 변경하여 작업을 진행했다. 응답 코드별로 응답 데이터를 작성 방법이 제안되었고, 내일 API 명세서 전체 리뷰 이후에 논의하기로 했다.
FeignClient 특강
선언적 웹 서비스 클라이언트로, 복잡한 코드를 줄이고 선언만으로 클라이언트를 구현할 수 있다.
주요 내용
기본 사용법
@FeignClient를 통해 인터페이스로 선언만 하면 자동으로 구현된다.application.yaml에@EnableFeignClients어노테이션을 달아줘야한다.- 사용되는 DTO의 설정은 별도로 필요하다.
헤더 설정
3가지 방법이 있다.
- RequestInterceptor: 동일한 헤더를 여러 곳에서 재사용할 수 있다.
@RequestHeader: 동적으로 아규먼트를 전달한다.- 고정된 헤더를
@GetMapping(headers="key=value")로 설정한다.
에러 처리
- 중복된 try-catch:
@ExceptionHandler를 통해 공통으로 처리할 수 있다. - 요청별로 다르게 처리해야 하면
ErrorDecoder구현체를 사용한다. - 기본적으로 응답코드가
200 ≥ 에러 ≤ 300이면 에러라고 간주한다.
Retry
동시에 많은 요청으로 주로 429 Too Many Requests 에러가 발생하는데, 일시적으로 거절되는 경우가 있으니 재시도 요청을 통해서 복구된 서버에게 요청할 수 있도록 재시도 로직을 설정을 한다.
CircuitBreaker
- 장애를 빠르게 탐지하고 서비스 안정성을 높일 수 있다.
- 간단하게 사용한다는 설정으로 기본적인 기능을 활성화 할 수 도 있다.
실전 라이브러리 팁
- 테스트 코드를 참고하면 이해도를 높일 수 있다.
- 코드 찾아서 뜯어볼때 테스트코드를 확인하면 이해를 높일 수 있다.
- Repository를 Clone받아서 GPT한테 물어보면 잘 찾아서 대답해준다.