HTTP Method 정리: GET, POST만 써도 될까? (REST vs RPC)

백엔드 개발을 하다 보면 이런 말을 한 번쯤 듣는다.

“GET, POST만 써도 돼”
“PUT, PATCH, DELETE 굳이 안 써도 되지 않나?”

이 말은 반은 맞고, 반은 틀리다.
이 글에서는 HTTP Method의 차이와 함께
REST 스타일과 RPC 스타일의 차이,
그리고 실무에서의 현실적인 기준을 정리해본다.

---

1. HTTP Method는 무엇을 의미할까?

HTTP Method는 단순히 “요청 타입”이 아니라
서버에게 이 요청이 어떤 의도를 가지는지 전달하는 수단이다.

Method의미

GET	조회
POST	생성 / 액션
PUT	전체 수정
PATCH	부분 수정
DELETE	삭제

👉 중요한 점은
Method = 행동, URL = 리소스라는 역할 분리다.

---

2. RPC 스타일이란?

RPC (Remote Procedure Call)

“서버의 함수를 원격으로 호출한다”는 사고방식

특징

• URL에 동작(동사) 가 들어간다
• Method는 거의 POST만 사용한다

예시

 

POST /comments/write POST /comments/delete POST /comments/update POST /articles/getDetail

이 방식은:

• 구현이 쉽고
• 프론트에서도 직관적이다

그래서 실무에서도 실제로 많이 쓰인다.

---

3. REST 스타일이란?

REST (Representational State Transfer)

“리소스를 중심으로 상태를 다룬다”는 사고방식

특징

• URL은 명사(리소스) 중심
• 행동은 HTTP Method로 표현

예시

 

GET /articles/{id}/comments POST /articles/{id}/comments PATCH /comments/{id} DELETE /comments/{id}

URL만 봐도:

• 어떤 리소스인지
• 어떤 관계인지
• 어떤 동작인지
  가 드러난다.

---

4. RPC vs REST 비교

구분RPC 스타일REST 스타일

URL	동사 중심	명사 중심
Method	거의 POST	의미 명확
설계 난이도	낮음	높음
확장성	낮음	높음
외부 API	부적합	적합

👉 작은 서비스, 내부용 → RPC
👉 확장, 협업, 공개 API → REST

---

5. PUT / PATCH / DELETE는 언제 쓰는가?

PUT – 전체 수정

 

PUT /users/10

• 리소스를 완전히 덮어씀
• 모든 필드를 다시 보내야 함
• 실무에서는 거의 사용하지 않음

---

PATCH – 부분 수정 (실무 최다 사용)

 

PATCH /comments/5

 

{ "content": "수정된 댓글" }

• 일부 필드만 변경
• 댓글 수정, 프로필 수정 등 대부분 PATCH

---

DELETE – 삭제

 

DELETE /comments/5

• 의미가 가장 명확
• soft delete여도 DELETE 사용

---

6. “GET / POST만 써도 된다”는 말의 진짜 의미

이 말은 완전히 틀린 말은 아니다.

이 말이 성립하는 상황

• 내부 서비스
• 빠른 개발이 중요한 경우
• 팀 내 합의가 명확한 경우

 

POST /comments/delete POST /comments/update

👉 실제로 이런 API는 매우 많다.

---

하지만 단점도 분명하다

• URL 개수가 급증
• 규칙이 흐트러짐
• API 문서 없으면 이해 어려움
• 외부 공개 API로 부적합

---

7. 실무에서 추천하는 현실적인 기준

REST를 기본으로 설계하고,
필요한 경우 RPC를 섞는다

추천 기준 정리

• CRUD → REST
• 생성 → POST
• 조회 → GET
• 수정 → PATCH
• 삭제 → DELETE
• 상태 전이 / 액션 → RPC (/like, /publish)

---

8. 핵심 요약

• RPC: “이 함수 실행해”
• REST: “이 리소스를 이렇게 다뤄”
• GET/POST만 써도 되지만 → 설계 실력은 쌓이지 않는다
• PATCH / DELETE는 의미 전달을 위한 도구

---

마무리

HTTP Method를 많이 쓰는 게 중요한 게 아니다.
왜 이 Method를 쓰는지 설명할 수 있는가가 중요하다.

REST를 제대로 한 번 설계해본 경험은
나중에 RPC 스타일을 쓰더라도
훨씬 의식적인 선택을 하게 만들어준다.