🌐 RESTful API란? 쉽게 정리한 개념과 예시

백엔드 개발을 시작하면 꼭 듣게 되는 말,
“RESTful하게 설계해야지!”
하지만...
REST? RESTful? 이게 도대체 뭔데?

이 글에서는 RESTful API의 개념부터 원칙, 실제 예시까지
한 번에 쏙 정리해드립니다!

---

✅ 1. REST란?

REST는

REpresentational State Transfer의 약자입니다.

📌 웹의 기본 원칙을 잘 따르는 소프트웨어 아키텍처 스타일이에요.
REST는 HTTP 기반의 자원(Resource) 중심 통신 방식입니다.

---

🚀 2. REST API란?

REST 원칙을 지키며 만든 API를 RESTful API라고 부릅니다.

즉, 웹에서 자원을 URI로 표현하고,
**HTTP 메서드(GET, POST, PUT, DELETE 등)**를 통해 자원을 다루는 API입니다.

---

🧱 3. REST의 핵심 원칙

원칙설명

자원(URI)	모든 것은 고유한 URI로 표현
행위(Method)	자원에 대한 동작은 HTTP 메서드로 구분
무상태성(Stateless)	요청 간 상태를 서버가 기억하지 않음
클라이언트-서버 구조	역할 분리 (프론트 ↔ 백엔드)
계층 구조	서버는 중간 계층을 둘 수 있음 (ex. 캐시, 프록시 등)

---

📌 4. RESTful API 예시

블로그 게시글 관련 API를 만든다고 해봅시다.

📄 자원: posts

동작HTTP MethodURI 예시설명

전체 조회	GET	/posts	게시글 전체 목록 조회
단일 조회	GET	/posts/1	ID 1번 게시글 조회
생성	POST	/posts	새 게시글 생성
수정	PUT	/posts/1	ID 1번 게시글 수정
삭제	DELETE	/posts/1	ID 1번 게시글 삭제

💡 요점:

• 자원은 URI로 식별
• 동작은 HTTP 메서드로 구분

---

⚙️ 4-1. 주요 HTTP 메서드 정리

RESTful API에서 자원에 대한 동작은 다음과 같은 HTTP 메서드로 표현됩니다.

메서드의미사용 예시설명

GET	조회	/posts, /posts/1	자원을 가져올 때 사용합니다. 서버에 영향을 주지 않습니다.
POST	생성	/posts	새로운 자원을 생성할 때 사용합니다. 보통 **본문(body)**에 데이터를 함께 보냅니다.
PUT	전체 수정	/posts/1	해당 자원의 전체를 수정할 때 사용합니다. 없으면 새로 생성되기도 합니다.
PATCH	부분 수정	/posts/1	자원의 일부분만 수정할 때 사용합니다.
DELETE	삭제	/posts/1	해당 자원을 삭제합니다.

🧠 추가 팁

• GET 요청은 URL에 쿼리 파라미터를 붙이는 방식으로 데이터를 전달합니다.
  👉 예: /posts?user=kim
• POST, PUT, PATCH는 Request Body에 JSON 등으로 데이터를 포함시킵니다.
• REST에서는 POST를 주로 생성(create) 에만 쓰고, 수정은 PUT이나 PATCH로 분리하는 게 일반적입니다.

---

✅ 예시로 다시 보기

게시글 생성

POST /posts
Content-Type: application/json

{
  "title": "REST API란?",
  "content": "이해하기 쉬운 설명입니다."
}

게시글 수정

PUT /posts/1
Content-Type: application/json

{
  "title": "REST API 완전 정복!",
  "content": "전체 내용을 덮어씁니다."
}

---

📌 정리

RESTful API는 동사를 URI에 넣지 않고,
HTTP 메서드로 행위를 구분하는 것이 핵심입니다.

즉,

• /getAllPosts ❌
• GET /posts ✅

---

🧠 5. RESTful하지 않은 예시

 

GET /getPost?id=1
POST /createNewPost

왜냐하면 자원을 URI에 표현하지 않고, 동작을 URI로 표현했기 때문입니다.

---

✨ 6. RESTful API의 장점

• ✅ 구조가 명확하고 직관적
• ✅ URL만 봐도 무슨 API인지 알 수 있음
• ✅ HTTP 표준을 그대로 사용 → 호환성 좋음
• ✅ 다양한 클라이언트에서 쉽게 사용할 수 있음

---

❗ 7. 주의사항: RESTful ≠ 무조건 정답

RESTful 설계가 깔끔하긴 하지만,
모든 상황에 꼭 REST만 고집할 필요는 없습니다.

필요에 따라 GraphQL, RPC 방식 등 다른 방식도 고려해보세요!

---

✅ 8. 정리

개념설명

REST	자원 중심 아키텍처 스타일
REST API	REST 원칙을 따르는 API
RESTful	REST에 부합하게 설계된 상태
핵심 요소	URI, HTTP Method, 무상태성 등