HTTP 메서드 올바른 사용법 완벽 가이드

REST API 개발할 때 꼭 알아야 하는 HTTP 메서드들! GET, POST, PUT, PATCH, DELETE의 차이점과 올바른 사용법을 실무 예제와 함께 쉽게 알려드려요.

---

목차

1. GET_리소스_조회
2. POST_리소스_생성
3. PUT_vs_PATCH_차이점
4. DELETE_리소스_삭제
5. 멱등성_Idempotent_개념
6. 안전한_메서드_vs_비안전한_메서드

---

1. GET 리소스 조회

이거 진짜 기본 중의 기본이에요! API 호출의 80%는 GET이라고 해도 과언이 아니거든요.

GET은 서버에서 데이터를 읽어올 때 쓰는 메서드예요. 데이터를 바꾸지 않고, 그냥 조회만 해요.

브라우저 주소창에 URL 치면 그게 바로 GET 요청이에요!

다음 코드를 살펴봅시다.

// 💡 GET: 데이터 조회 전용!
// ✅ 유저 목록 가져오기
fetch('/api/users')
  .then(res => res.json())
  .then(users => console.log(users));

// ✅ 특정 유저 조회 (ID로)
fetch('/api/users/123')
  .then(res => res.json())
  .then(user => console.log(user));

// ✅ 검색 조건 추가 (쿼리스트링)
fetch('/api/users?role=admin&active=true')
  .then(res => res.json())
  .then(admins => console.log(admins));

🤔 왜 이게 필요할까요? 웹사이트 들어가면 뭐가 보이죠? 유저 목록, 상품 정보, 게시글...

이거 다 서버에서 가져온 데이터예요. 💡 핵심 개념 GET은 "야, 이 데이터 좀 줘"예요.

도서관에서 책 빌리는 거랑 똑같아요. 책을 가져오지, 책 내용을 바꾸진 않잖아요?

⚡ GET의 특징 - 안전해요: 서버 데이터 안 바뀜 - 캐싱 가능: 브라우저가 저장해둠 - 북마크 가능: URL에 다 담겨있음 ✨ 쿼리스트링 활용법 URL 뒤에 ?로 조건을 붙여요. /users?page=2&limit=10 이렇게 하면 2페이지, 10개씩!

🔍 코드 뜯어보기 fetch의 기본이 GET이에요. method 안 적으면 자동으로 GET!

쿼리스트링으로 필터링도 가능하죠. 🎯 실무에서는 이렇게 써요 리스트 페이지 들어가면 GET.

상세 페이지 들어가면 GET. 검색하면?

역시 GET이에요. ⚠️ 주의할 점 GET으로 데이터 수정하면 안 돼요!

/deleteUser?id=123 이런 거 절대 NO! 보안상 큰 문제가 생겨요.

🚀 한 줄 정리 GET = 읽기 전용, 서버에 흔적 없이 조회만!

실전 팁

💡 GET 요청은 body 없이 URL로만 데이터 전달해요

💡 민감한 정보는 GET 쿼리스트링에 넣지 마세요

---

2. POST 리소스 생성

회원가입, 글쓰기, 댓글 달기... 뭔가 새로 만들 때는 POST예요!

POST는 서버에 새로운 데이터를 생성할 때 사용해요. 요청할 때마다 새로운 리소스가 생겨요.

같은 요청 두 번 보내면? 두 개가 생겨요!

다음 코드를 살펴봅시다.

// 💡 POST: 새로운 리소스 생성!
// ✅ 새 유저 생성 (회원가입)
fetch('/api/users', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    name: '김개발',
    email: 'dev@test.com',
    password: 'secure123'
  })
})
.then(res => res.json())
.then(newUser => {
  // 🎉 생성된 유저 정보 (id 포함)
  console.log('생성됨:', newUser.id);
});

🤔 왜 이게 필요할까요? 회원가입 버튼 눌러본 적 있죠? 그때 서버에 내 정보가 새로 생성돼요.

이게 바로 POST예요! 💡 핵심 개념 POST는 "야, 이거 새로 만들어줘"예요.

택배 보내는 거랑 비슷해요. 받는 사람한테 새 물건이 전달되잖아요.

⚡ GET vs POST 차이 - GET: 데이터 읽기 (조회) - POST: 데이터 쓰기 (생성) 완전 반대 역할이에요! ✨ POST의 특징 - body에 데이터 담아요: JSON 형태로 - 캐싱 안 됨: 매번 새로 요청 - 멱등성 없음: 두 번 보내면 두 개 생김!

🔍 코드 뜯어보기 method: 'POST' 명시해줘야 해요. body에 JSON으로 데이터 담고요.

headers에 Content-Type도 필수! 🎯 실무에서는 이렇게 써요 폼 제출할 때 POST.

파일 업로드할 때 POST. 결제 요청할 때도 POST예요.

⚠️ 주의할 점 POST는 멱등성이 없어요. 실수로 두 번 클릭하면 두 개 생겨요!

그래서 중복 클릭 방지가 중요해요. 🚀 한 줄 정리 POST = 새로 만들기, body에 데이터 담아서 전송!

실전 팁

💡 Content-Type: application/json 헤더 까먹지 마세요

💡 버튼 중복 클릭 방지 로직 꼭 넣어요

---

3. PUT vs PATCH 차이점

솔직히 이거 제대로 구분하는 사람 별로 없어요! 면접 단골 질문이기도 하죠.

PUT은 전체 교체, PATCH는 부분 수정이에요. 유저 이름만 바꾸고 싶으면 PATCH, 유저 정보 전체를 덮어쓰고 싶으면 PUT을 써요!

다음 코드를 살펴봅시다.

// 💡 PUT: 전체 교체 (모든 필드 필요)
fetch('/api/users/123', {
  method: 'PUT',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    name: '김개발',      // 모든 필드
    email: 'new@test.com', // 다 넣어야
    age: 28,             // 해요!
    role: 'admin'
  })
});

// 💡 PATCH: 부분 수정 (바꿀 것만!)
fetch('/api/users/123', {
  method: 'PATCH',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    name: '박개발'  // ✅ 이름만 수정!
  })
});

🤔 왜 이게 필요할까요? 프로필 수정할 때 이름만 바꾸고 싶은데... 모든 정보를 다 보내야 할까요?

이럴 때 PUT vs PATCH 구분이 필요해요! 💡 핵심 개념 PUT은 문서 전체 교체예요.

PATCH는 스티커 붙이기예요. 전체를 바꾸느냐, 일부만 고치느냐!

⚡ 비유로 이해하기 PUT: 이력서 전체를 새로 작성 PATCH: 이력서에서 연락처만 수정 어떤 게 더 효율적인지 감 오죠? ✨ PUT의 특징 - 리소스 전체를 교체해요 - 안 보낸 필드는 null이 될 수 있어요 - 멱등성 있음: 여러 번 해도 결과 같음 🔍 PATCH의 특징 - 일부 필드만 수정해요 - 보낸 것만 바뀌고 나머진 그대로!

• 네트워크 비용도 적게 들어요 🎯 실무에서는? 솔직히 PATCH를 더 많이 써요. 프로필 수정, 설정 변경 등 대부분 일부만 바꾸거든요.

⚠️ 주의할 점 PUT에서 필드 빼먹으면 큰일나요! 기존 데이터가 날아갈 수 있어요.

확실하지 않으면 PATCH 쓰세요. 🚀 한 줄 정리 PUT = 갈아엎기, PATCH = 고치기!

실전 팁

💡 대부분의 수정 작업엔 PATCH가 안전해요

💡 API 문서 보고 뭘 지원하는지 확인하세요

---

4. DELETE 리소스 삭제

이름 그대로예요! 뭔가 지울 때 쓰는 메서드죠.

DELETE는 서버의 리소스를 삭제할 때 사용해요. 단순하지만 위험할 수 있어서 권한 체크가 중요해요.

보통 body 없이 URL의 ID만으로 삭제해요!

다음 코드를 살펴봅시다.

// 💡 DELETE: 리소스 삭제!
// ✅ 특정 유저 삭제
fetch('/api/users/123', {
  method: 'DELETE',
  headers: {
    'Authorization': 'Bearer token123'  // 🔐 권한 필수!
  }
})
.then(res => {
  if (res.status === 204) {
    console.log('삭제 완료!');  // 204 No Content
  }
});

// ✅ 여러 개 삭제 (body 사용하는 경우)
fetch('/api/users', {
  method: 'DELETE',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ ids: [1, 2, 3] })
});

🤔 왜 이게 필요할까요? 회원 탈퇴, 게시글 삭제, 댓글 삭제... 데이터를 지워야 할 때가 있잖아요.

그때 DELETE를 써요! 💡 핵심 개념 DELETE는 "야, 이거 지워줘"예요.

휴지통에 버리는 거랑 같아요. 근데 진짜 지워지니까 조심해야 해요!

⚡ DELETE의 특징 - URL에 삭제할 ID 명시 - 보통 body 없이 보냄 - 성공하면 204 No Content ✨ 응답 코드 알아두기 - 200 OK: 삭제 완료 + 삭제된 데이터 반환 - 204 No Content: 삭제 완료 (응답 body 없음) - 404 Not Found: 이미 없는 리소스 🔍 코드 뜯어보기 method: 'DELETE' 명시하고요. 인증 토큰 꼭 보내야 해요.

아무나 삭제하면 안 되잖아요! 🎯 실무에서는 이렇게 써요 실제로는 Soft Delete 많이 써요.

진짜 지우지 않고 deleted_at 표시만! 나중에 복구할 수 있게요.

⚠️ 주의할 점 DELETE는 되돌릴 수 없어요! 그래서 "정말 삭제하시겠습니까?" 물어보죠.

권한 체크도 꼼꼼히 해야 해요. 🚀 한 줄 정리 DELETE = 삭제, 권한 체크 필수, 신중하게!

실전 팁

💡 실무에선 Soft Delete (논리 삭제) 고려하세요

💡 삭제 전 확인 다이얼로그 꼭 띄우세요

---

5. 멱등성 Idempotent 개념

이거 면접에서 엄청 자주 물어봐요! 근데 이름이 어려워서 겁먹는 분 많더라고요.

멱등성은 같은 요청을 여러 번 보내도 결과가 같은 것이에요. GET, PUT, DELETE는 멱등하고, POST는 멱등하지 않아요.

API 설계할 때 꼭 알아야 해요!

다음 코드를 살펴봅시다.

// 💡 멱등성 비교!

// ✅ GET - 멱등함
// 100번 조회해도 결과 같음
fetch('/api/users/1');  // 유저 정보
fetch('/api/users/1');  // 똑같은 유저 정보

// ✅ PUT - 멱등함
// 100번 수정해도 최종 결과 같음
fetch('/api/users/1', { method: 'PUT', body: {...} });

// ✅ DELETE - 멱등함
// 이미 삭제된 건 또 삭제해도 결과 같음
fetch('/api/users/1', { method: 'DELETE' });

// ❌ POST - 멱등하지 않음!
// 보낼 때마다 새로운 리소스 생성됨
fetch('/api/users', { method: 'POST', body: {...} }); // 유저1 생성
fetch('/api/users', { method: 'POST', body: {...} }); // 유저2 생성!

🤔 왜 이게 필요할까요? 네트워크 끊겼다가 재시도하면? 결제가 두 번 되면 큰일이잖아요!

멱등성 이해하면 이런 문제 예방돼요. 💡 핵심 개념 멱등성 = 여러 번 해도 결과 같음 리모컨 ON 버튼 생각해보세요.

TV 켜진 상태에서 또 눌러도 켜진 상태죠! ⚡ 멱등한 메서드들 - GET: 조회만 하니까 당연히 멱등 - PUT: 같은 값으로 덮어쓰니까 멱등 - DELETE: 이미 없으면 또 삭제해도 없음 ✨ POST가 멱등하지 않은 이유 POST는 새로 만드는 거예요.

같은 정보로 두 번 보내면? 똑같은 유저가 두 명 생겨요!

🔍 실제 상황 예시 결제 API를 POST로 만들었어요. 네트워크 오류로 재전송됐는데...

두 번 결제되면 민원 폭주예요! 😱 🎯 실무에서는 이렇게 해요 POST 요청에 중복 방지 토큰 넣어요.

Idempotency-Key 헤더 사용! 같은 키로 오면 이전 결과 반환해요.

⚠️ 면접 대비 포인트 "멱등성이 뭔가요?" 물어보면 "같은 요청 여러 번 해도 결과 같아요" 그리고 GET/PUT/DELETE vs POST 비교! 🚀 한 줄 정리 멱등성 = 여러 번 = 한 번, POST만 빼고 다 멱등!

실전 팁

💡 결제 같은 중요한 POST엔 Idempotency-Key 쓰세요

💡 면접에서 자주 나오니 꼭 외워두세요

---

6. 안전한 메서드 vs 비안전한 메서드

안전하다는 게 뭘까요? 보안 얘기 아니에요!

서버 데이터를 바꾸느냐 마느냐 얘기예요.

안전한 메서드는 서버의 상태를 변경하지 않는 메서드예요. GET, HEAD, OPTIONS가 안전해요.

POST, PUT, PATCH, DELETE는 비안전해요. 캐싱이나 프리페칭에 영향을 줘요!

다음 코드를 살펴봅시다.

// 💡 안전한 메서드 vs 비안전한 메서드

// ✅ 안전한 메서드 (서버 상태 변경 X)
fetch('/api/users', { method: 'GET' });     // 조회만
fetch('/api/users', { method: 'HEAD' });    // 헤더만
fetch('/api/users', { method: 'OPTIONS' }); // 옵션 확인

// ❌ 비안전한 메서드 (서버 상태 변경 O)
fetch('/api/users', { method: 'POST', body });   // 생성
fetch('/api/users/1', { method: 'PUT', body });  // 교체
fetch('/api/users/1', { method: 'PATCH', body }); // 수정
fetch('/api/users/1', { method: 'DELETE' });     // 삭제

// 💡 브라우저 프리페칭 예시
// <link rel="prefetch" href="/api/data">
// ⚠️ GET만 프리페칭 가능! (안전하니까)

🤔 왜 이게 필요할까요? 브라우저가 미리 데이터 가져오는 거 알죠? 만약 DELETE를 미리 실행하면?

데이터 다 날아가요! 😱 💡 핵심 개념 안전 = 서버 데이터 안 바뀜 도서관에서 책 목록 보는 건 안전해요.

책을 빌리거나 반납하는 건 비안전하고요. ⚡ 안전한 메서드 종류 - GET: 조회만 함 - HEAD: 헤더만 확인 - OPTIONS: 뭐가 가능한지 확인 ✨ 비안전한 메서드 종류 - POST: 새로 만듦 - PUT/PATCH: 수정함 - DELETE: 삭제함 전부 서버 데이터를 바꾸죠!

🔍 왜 구분이 중요할까? 브라우저는 안전한 요청만 마음대로 해요. 프리페칭, 캐싱, 재시도...

비안전한 건 유저 동의 없이 안 해요! 🎯 실무 영향 크롬이 링크 위에 마우스 올리면?

GET 요청 미리 보내요 (프리페칭). DELETE였으면...

상상만 해도 끔찍하죠? ⚠️ 설계 시 주의점 삭제를 GET으로 만들면 안 돼요!

/delete?id=123 이런 거 절대 NO! 검색 엔진 크롤러가 다 삭제해버려요.

🚀 한 줄 정리 안전 = 읽기만, GET은 맘껏 호출해도 OK!

실전 팁

💡 조회는 무조건 GET, 절대 다른 메서드 쓰지 마세요

💡 중요한 작업은 비안전한 메서드 + 권한 체크로!

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!