홈 › 실무 확장 › 07 / 22

REST API 서버와 JSON

CRUD, 상태 코드, 에러 규격, 검증, 페이징
섹션 7진행 0 / 22

7. 정리

  • REST 경로는 명사·복수형으로 자원을 가리키고, "무엇을 하는지"는 메서드가 말합니다. GET/PUT/DELETE 는 멱등, POST 는 아닙니다.
  • 상태 코드는 클라이언트의 행동을 결정하는 신호입니다. 성공도 실패도 200 으로 뭉개면 캐시·재시도·에러 핸들링이 전부 무력화됩니다.
  • 에러는 {code, message, errors, traceId, timestamp} 로 규격화하고, RFC 9457 problem+json 이 표준 대안입니다. 예외 메시지는 절대 그대로 노출하지 않습니다.
  • 검증은 형식 → 필수 → 업무 규칙 순서로 하고, "요청 자체 문제"는 400, "지금 상태와 충돌"은 409, "형식은 맞지만 처리 불가"는 422 로 나눕니다.
  • JSON 직렬화에서 long id 는 문자열로, 날짜는 Instant + ISO-8601 로 내보내야 프런트에서 정밀도·시간대 버그가 안 생깁니다.
  • 동시 수정은 version 필드 또는 ETag/If-Match 로 감지해 409 로 막습니다. 페이징은 오프셋이 기본이지만 대용량은 키셋 페이징으로 옮깁니다.
  • 라우팅은 결국 "경로 패턴을 정규식으로 컴파일해 매칭하고 변수를 추출"하는 일이며, Spring 의 @PathVariable 도 이 원리 위에 있습니다.
  • Spring Boot 3.5 는 @RestController/@Valid/ResponseEntity/@RestControllerAdvice/Pageable 로 이 레슨의 각 부분을 대신하고, Vue/axios 는 응답 인터셉터에서 이 레슨의 에러 규격을 한곳에서 처리합니다.

다음 실무 확장 레슨에서는 이 회원 API 를 실제 DB(H2/MyBatis, 이전 레슨에서 다룸)와 묶고, 인증 레벨의 JWT 로 보호 자원으로 승격하는 흐름을 다룹니다.

이 레슨의 11개 파일은 그대로 하나의 작은 Spring Boot 프로젝트로 옮겨볼 수 있는 크기입니다. Router 를 @RestController 로, MemberStore 를 JpaRepository 로 바꿔보면 각 계층이 실무에서 무엇을 대신하는지 더 분명해집니다.