06장 블로그 기획하고 API 만들기

💡 이 글은 골든래빗 《스프링 부트 3 백엔드 개발자 되기 - 자바 편》의 06장 써머리입니다.

핵심 키워드

REST API

• Representational State Transfer Application Programming Interface
• (자원의) 구체적인 상태를 (변화시키는 메시지를 HTTP로) 전송하는 API (설계방식)
• URL 설계방식을 의미
  • URL에는 동사를 쓰지 않고 자원을 복수와 단수로 표시
  • 동사는 HTTP 메서드로 표현 — POST, GET, DELETE, PUT, …
    • GET localhost:8080/api/articles/1
    • POST localhost:8080/api/articles/2
    • PUT localhost:8080/api/articles/3
    • DELETE localhost:8080/api/articles/1

CRUD — HTTP Method 위주로

• @PostMapping("/api/articles")
  • articles → article 이게 더 어울리지 않을까? 글 작성을 동시에 여러 개 쓰는 것이 아니니
• PUT vs PATCH
  • PUT
    • 기존 리소스가 있으면 대체, 없으면 생성
    • 새 객체에 빈 값이 있거나 없으면 기존 데이터가 사라지므로 주의
    • 클라이언트가 리소스 위치를 알고 URI를 지정하여 요청
  • PATCH
    • 리소스 부분 변경
    • 기존 객체가 여러 데이터를 담고 있어도 필드 1개만 PATCH 요청 시 해당 값만 변경됨
• BlogService.update()

  @Transactional
  public Article update(long id, UpdateArticleRequest request) {
      Article article = blogRepository.findById(id)
              .orElseThrow(() -> new IllegalArgumentException("not found: " + id));
  
      article.update(request.getTitle(), request.getContent());
  
      return article;
  }

  • 책에선 간단하게 지나갔지만 객체지향 설계, JPA 변경감지 개념이 나타남
  • 객체의 책임과 역할 관점에서 Article 엔티티 안의 데이터를 수정하는 역할은 누가 해야 하는가? 라고 생각해 봤을 때, 서비스 계층이 아닌, 데이터에 대해 가장 많은 정보를 가지고 있는 Article이 수정해야 함
  • article.update 메서드는 단지 필드값을 변경만 하지만 JPA로 처리될 때는 1차 캐시에 저장된 article의 스냅샷과 비교해 UPDATE SQL이 생성되어 DB에 적용된다. UPDATE문 관련 코드를 작성하지 않아도 자동으로 반영됨

Lombok 사용 시 주의점

• 필드가 많으면 @Builder 사용 권장 — 필드 순서 변경에 따른 오류 위험 방지
• https://kwonnam.pe.kr/wiki/java/lombok/pitfall