◇ PART · REST

HTTP 메서드 어노테이션

Get / Post / Put / Delete Mapping

학습 목표

  • HTTP 4 가지 메서드 (GET·POST·PUT·DELETE) 의 역할을 안다
  • Spring 의 매핑 어노테이션을 메서드별로 안다
  • RESTful URL 디자인 의 기본을 안다
  • 같은 URL 에 다른 메서드로 다른 동작을 분기시킨다

⚠️ 옛 스타일 URL 의 문제

전통적인 게시판 URL

GET  /board/list            ← 목록
GET  /board/view?num=3      ← 상세
GET  /board/writeForm       ← 작성 폼
POST /board/write           ← 작성 처리
GET  /board/editForm?num=3  ← 수정 폼
POST /board/update          ← 수정 처리
POST /board/delete?num=3    ← 삭제 처리

규칙이 없습니다. URL 만 봐서는 무엇을 하는지 알기 어렵고 — 다른 시스템과 연동할 때 매번 「우리 사이트는 어떻게 짰는가」 설명서를 써야 합니다.

🛠️ RESTful 의 발상

「리소스 = URL, 동작 = HTTP 메서드」

URL 은 「무엇」(boards) 만 표현하고, 「어떤 동작」(조회·생성·수정·삭제) 은 HTTP 메서드로 표현.

동작옛 스타일RESTful
목록GET /board/listGET /api/boards
상세GET /board/view?num=3GET /api/boards/3
작성POST /board/writePOST /api/boards
수정POST /board/update?num=3PUT /api/boards/3
삭제POST /board/delete?num=3DELETE /api/boards/3

4 가지 핵심 HTTP 메서드

메서드의미Spring 어노테이션
GET조회 — 데이터 가져오기@GetMapping
POST생성 — 새 데이터 만들기@PostMapping
PUT수정 — 기존 데이터 변경 (전체)@PutMapping
DELETE삭제 — 데이터 지우기@DeleteMapping
PATCH부분 수정@PatchMapping

👉 본 과정은 4 개로 충분. PATCH 는 후속 과정.

같은 URL, 다른 메서드


@RestController
@RequestMapping("/api/boards")
public class BoardApiController {

    @GetMapping("/{num}")            // GET /api/boards/3
    public Board view(@PathVariable int num) {
        return service.selectOne(num);
    }

    @PutMapping("/{num}")            // PUT /api/boards/3
    public Board update(@PathVariable int num,
                         @RequestBody Board b) {
        b.setNum(num);
        return service.update(b);
    }

    @DeleteMapping("/{num}")         // DELETE /api/boards/3
    public void delete(@PathVariable int num) {
        service.delete(num);
    }
}

👉 같은 URL /api/boards/3 에서 메서드만 다르면 다른 처리.

각 메서드의 약속 — 멱등성

메서드안전한가?
(데이터 변경 X)
멱등?
(여러 번 = 한 번)
GET
POST
PUT
DELETE

👉 멱등 (idempotent) = 같은 요청을 여러 번 보내도 결과가 같음.
PUT 으로 같은 데이터를 100 번 전송 = 한 번 전송과 결과 같음.
POST 는 100 번 전송 = 글이 100 개 생성.

왜 멱등성이 중요한가

네트워크가 불안하면 클라이언트가 「응답이 안 와서」 같은 요청을 다시 보낼 수 있습니다.

  • POST 재전송 = 글 두 번 등록 (위험!)
  • PUT 재전송 = 같은 결과 (안전)
  • DELETE 재전송 = 이미 지워진 것 또 지움 (안전)

그래서 「새 데이터 만들기」 만 POST 로 하고, 「특정 데이터 변경」 은 PUT 으로 합니다. 안전성의 차이.

RESTful URL 설계 규칙

① 명사를 사용 (동사 X)


✗ POST /api/createBoard
✓ POST /api/boards

✗ GET  /api/getBoard?id=3
✓ GET  /api/boards/3

② 복수형 사용


✗ /api/board/3
✓ /api/boards/3      ← 「게시판들 중 3 번」

③ 계층 구조 표현


GET  /api/boards/3/replies        ← 3 번 글의 댓글들
POST /api/boards/3/replies         ← 3 번 글에 댓글 추가
DELETE /api/boards/3/replies/7     ← 3 번 글의 7 번 댓글 삭제

실제 예시 — 게시판 + 댓글 API

메서드URL동작
GET/api/boards게시글 목록
GET/api/boards/33 번 게시글
POST/api/boards새 게시글 작성
PUT/api/boards/33 번 게시글 수정
DELETE/api/boards/33 번 게시글 삭제
GET/api/boards/3/replies3 번 글의 댓글들
POST/api/boards/3/replies3 번 글에 댓글 추가
DELETE/api/boards/3/replies/73 번 글의 7 번 댓글 삭제

POST vs PUT — 헷갈리기 쉬움

둘 다 「변경」 같지만 용도가 다릅니다:

POSTPUT
새로 만들기 (id 모름)특정 id 의 데이터 변경
/api/boards (id 없음)/api/boards/3 (id 있음)
서버가 id 부여클라이언트가 id 지정
멱등 X멱등 ✓

응답 상태 코드 — 메서드별 표준

메서드성공 시실패 시
GET200 OK404 Not Found / 401 Unauthorized
POST201 Created (또는 200)400 Bad Request
PUT200 OK / 204 No Content404 / 400
DELETE204 No Content404 / 403

👉 본 과정에서는 기본 200 으로 충분. 상세한 응답 상태 코드 디자인은 후속 과정.

본 과정의 변환 — v6 → v8

v6 (전통) v8 (REST) ───────── ───────── GET /board/list GET /api/boards GET /board/view?num=3 GET /api/boards/3 POST /board/write POST /api/boards POST /board/update PUT /api/boards/3 POST /board/delete?num=3 DELETE /api/boards/3 ※ 둘 다 같은 BoardService 호출 ※ 둘 다 우리 게시판의 핵심 동작 동일 ※ URL 표현 방식만 변경

실험 — Postman 으로 PUT/DELETE 보내기

  1. Postman 설치 (또는 VS Code REST Client 확장)
  2. PUT 요청 작성:
    
    URL: http://localhost:8080/.../api/boards/3
    Method: PUT
    Headers: Content-Type: application/json
    Body: {"title": "수정된 제목", "content": "수정된 내용"}
    
  3. 「Send」 클릭 → 수정 결과 확인
  4. DELETE 요청도 같은 방식으로 테스트

👉 브라우저 주소창은 GET 만 가능. PUT/DELETE 는 Postman 또는 fetch.

F12 fetch 로 직접 호출


// PUT — F12 Console 에서 실행
await fetch('/api/boards/3', {
    method: 'PUT',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify({title: '새 제목', content: '새 내용'})
}).then(r => r.json());

// DELETE — F12 Console
await fetch('/api/boards/3', {
    method: 'DELETE'
});

👉 Postman 없어도 F12 콘솔에서 즉시 테스트 가능.

주의 — HTML form 의 한계

form 은 GET / POST 만

HTML 의 <form> 태그는 method="get" 또는 method="post" 만 지원. PUT/DELETE 를 form 으로 직접 보낼 수 없음.


<form method="put"> ... </form>   ← 무시되고 GET 으로 처리됨

PUT/DELETE 를 보내려면 — JS 의 fetch 사용. 이게 REST API 가 자연스럽게 비동기와 어울리는 이유.

실수하기 쉬운 함정

증상원인
405 Method Not Allowed매핑된 메서드와 요청 메서드 불일치
404 Not FoundURL 오타 / @PathVariable 이름 다름
PUT 으로 보냈는데 처리 안 됨HTML form 으로 보냈을 가능성 (form 은 PUT 안 됨)
@RequestBody nullContent-Type: application/json 누락
@PathVariable 못 찾음URL의 {num} 과 매개변수 이름 불일치

다음 차시 — v8 변환

★ v8 차시에서 우리는 v6 의 BoardController 를 통째로 BoardApiController 로 옮깁니다. 그때 필요한 것이 오늘 배운:

  • 4 가지 메서드별 어노테이션 (@GetMapping ~ @DeleteMapping)
  • RESTful URL 디자인 (리소스는 명사·복수형)
  • POST vs PUT 의 차이
  • 같은 URL 에 여러 메서드 매핑

🔄 Before / After

전 차시 끝

@GetMapping, @PostMapping 정도만 안다. PUT/DELETE 는 들어본 정도.

이번 차시 끝

RESTful URL 디자인 패턴을 안다. 4 가지 메서드의 멱등성·용도·매핑 어노테이션 모두.

📊 한 그림 정리

이번 차시의 데이터 흐름

URL + Method
@GetMapping
@PostMapping
@PutMapping
@DeleteMapping
알맞은 메서드
「URL + 메서드」 두 차원으로 분기 — 같은 URL 도 메서드만 다르면 다른 처리

정리

오늘 들고 가는 것

  • 4 가지 메서드: GET (조회), POST (생성), PUT (수정), DELETE (삭제)
  • Spring 어노테이션: @GetMapping/@PostMapping/@PutMapping/@DeleteMapping
  • RESTful URL: 명사·복수형·계층 구조
  • POST 멱등 X / PUT·DELETE 멱등 ✓
  • HTML form 은 GET/POST 만 — PUT/DELETE 는 fetch 로

다음: ★ v8 REST 컨트롤러로 변환 — v6 게시판을 통째로 REST 로.