REST API: 두 판 사이의 차이

기술노트
편집 요약 없음
편집 요약 없음
 
(같은 사용자의 중간 판 하나는 보이지 않습니다)
1번째 줄: 1번째 줄:
== 🔁 RESTful API vs 비RESTful API 비교 ==
== 🔍 REST API란? ==


RESTful API는 REST 원칙(자원 중심 URI, HTTP 메서드의 의미, 상태 코드 사용 등)을 따르는 반면, 비RESTful API는 이를 지키지 않아 구조적으로 일관성이 떨어지고 유지보수가 어렵습니다.
'''REST API'''는 "Representational State Transfer" 원칙을 기반으로 만들어진 웹 API입니다.
웹의 자원을 URI로 표현하고, HTTP 메서드를 통해 자원에 대한 동작(조회, 생성, 수정, 삭제 등)을 수행합니다.


=== 📊 비교 표 ===
=== 🌐 REST란? ===
 
* REST는 2000년 로이 필딩(Roy Fielding)이 논문에서 제안한 '''웹 아키텍처 설계 원칙'''입니다.
* HTTP 프로토콜을 기반으로, 자원을 URI로 표현하고, 상태 전이(transfer)를 통해 자원을 조작하는 방식입니다.
* REST는 다음과 같은 6가지 제약 조건을 따릅니다:
# '''클라이언트-서버 구조''' – 클라이언트와 서버의 책임을 명확히 분리하여 역할 독립성과 확장성을 확보합니다.
# '''무상태성 (Stateless)''' – 요청 간 서버에 클라이언트 상태를 저장하지 않으며, 모든 요청은 독립적으로 처리됩니다.
# '''캐시 처리 가능''' – 응답에 캐시 가능 여부를 명시하여 클라이언트가 데이터를 효율적으로 재사용할 수 있습니다.
# '''계층화된 시스템''' – 클라이언트는 중간 계층(프록시, 게이트웨이 등)을 통해 서버에 접근할 수 있으며, 각 계층은 독립적으로 동작합니다.
# '''인터페이스 일관성 (Uniform Interface)''' – 모든 리소스는 일관된 방식(URI, HTTP 메서드 등)으로 접근되어야 하며, REST의 핵심 특징입니다.
# '''코드 온 디맨드 (선택적)''' – 클라이언트는 서버로부터 실행 가능한 코드를 전송받아 동적으로 기능을 확장할 수 있습니다 (예: JavaScript).
 
 
=== 🧱 REST API의 구성 요소 ===
 
* '''자원(Resource)''': URI로 식별되는 객체 (예: <code>/users</code>, <code>/posts/1</code>)
* '''메서드(Method)''': HTTP 메서드를 통해 자원에 대한 행위 지정
* '''표현(Representation)''': 자원의 데이터 형식 (JSON, XML 등)
* '''상태 코드(Status Code)''': 요청 처리 결과를 나타냄
 
=== 📌 HTTP 메서드 매핑 ===


{| class="wikitable"
{| class="wikitable"
|+ '''RESTful API vs 비RESTful API'''
|+ '''REST API에서의 HTTP 메서드 사용'''
! 구분 !! 비RESTful API !! RESTful API !! 설명
! 메서드 !! 의미 !! 예시
|-
|-
| URI 설계 || <code>/getUser?id=1</code> || <code>/users/1</code> || REST는 자원 중심 URI 사용, 동사는 피함
| GET || 리소스 조회 || <code>GET /users/1</code>
|-
|-
| HTTP 메서드 || <code>POST /deleteUser</code> || <code>DELETE /users/1</code> || 메서드 자체가 동작을 의미
| POST || 리소스 생성 || <code>POST /users</code>
|-
|-
| 리소스 명 || <code>/userlist</code>, <code>/createUser</code> || <code>/users</code> || 복수형 자원 명 사용
| PUT || 리소스 전체 수정 || <code>PUT /users/1</code>
|-
|-
| 상태 코드 || 항상 <code>200 OK</code> || <code>201</code>, <code>204</code>, <code>404</code> 등 || 클라이언트가 처리 결과를 정확히 알 수 있음
| PATCH || 리소스 일부 수정 || <code>PATCH /users/1</code>
|-
|-
| 동작 전달 방식 || <code>/do?action=delete&id=1</code> || <code>DELETE /users/1</code> || REST는 메서드+URI로 동작 구분
| DELETE || 리소스 삭제 || <code>DELETE /users/1</code>
|-
| 관계 표현 || <code>/getCommentsByPostId?id=10</code> || <code>/posts/10/comments</code> || URI 계층 구조로 관계 표현
|}
|}


---
=== ✅ REST API의 장점 ===


== ❌ 비RESTful API의 문제점 ==
* URI와 HTTP 메서드만으로도 의미가 명확하여 '''가독성'''과 '''일관성'''이 좋음
* '''표준 HTTP 기능 활용''' (캐시, 상태 코드 등)
* '''클라이언트와 서버의 역할 분리''' 가능
* 확장성과 유지보수가 뛰어남


* 동작의 의미가 URI에 노출되어 직관성이 떨어짐
=== ⚠️ REST API 주의사항 ===
* 클라이언트가 기능을 추측해야 하며, API 문서화가 어려움
* HTTP의 기능을 활용하지 못함 (상태 코드, 캐시, 멱등성 등)
* 자동화 도구(Swagger, Postman 등)와의 호환성 저하


---
* URI에는 '''동사 대신 명사'''를 사용해야 함 (예: <code>/users</code> OK, <code>/getUser</code>는 지양)
* 자원의 관계를 '''계층 구조 URI'''로 표현 (예: <code>/posts/10/comments</code>)
* 메서드의 의미와 일치하는 동작을 구현해야 함 (예: 삭제는 DELETE로 처리)


== ✅ RESTful API의 장점 ==
=== 📘 예시: 사용자 API ===
 
* '''표준화된 HTTP 메서드 활용''' (GET, POST, PUT, DELETE)
* '''자원 중심 URI 설계''' (예: <code>/users/1/orders</code>)
* '''명확한 상태 코드 제공''' → 에러 처리 용이
* '''확장성 우수''' → 기능 추가 및 구조 변경이 유연함
* '''API 문서화 및 테스트 도구와 호환 우수'''
 
---
 
== 🧪 실전 예시 ==
 
=== 사용자 삭제 요청 ===


{| class="wikitable"
{| class="wikitable"
|+ '''RESTful vs 비RESTful 예시'''
|+ '''REST API 설계 예시: 사용자(User)'''
! 방식 !! URI !! 메서드 !! 설명
! 동작 !! URI !! 메서드
|-
| 사용자 목록 조회 || <code>/users</code> || GET
|-
| 사용자 등록 || <code>/users</code> || POST
|-
| 특정 사용자 조회 || <code>/users/1</code> || GET
|-
|-
| 비RESTful || <code>/deleteUser?id=5</code> || POST || URI에 동사 사용, HTTP 메서드 고정
| 사용자 정보 수정 || <code>/users/1</code> || PUT 또는 PATCH
|-
|-
| RESTful || <code>/users/5</code> || DELETE || 자원과 동작 분리, 명확한 표현
| 사용자 삭제 || <code>/users/1</code> || DELETE
|}
|}

2025년 6월 24일 (화) 20:49 기준 최신판

🔍 REST API란?

REST API는 "Representational State Transfer" 원칙을 기반으로 만들어진 웹 API입니다. 웹의 자원을 URI로 표현하고, HTTP 메서드를 통해 자원에 대한 동작(조회, 생성, 수정, 삭제 등)을 수행합니다.

🌐 REST란?

  • REST는 2000년 로이 필딩(Roy Fielding)이 논문에서 제안한 웹 아키텍처 설계 원칙입니다.
  • HTTP 프로토콜을 기반으로, 자원을 URI로 표현하고, 상태 전이(transfer)를 통해 자원을 조작하는 방식입니다.
  • REST는 다음과 같은 6가지 제약 조건을 따릅니다:
  1. 클라이언트-서버 구조 – 클라이언트와 서버의 책임을 명확히 분리하여 역할 독립성과 확장성을 확보합니다.
  2. 무상태성 (Stateless) – 요청 간 서버에 클라이언트 상태를 저장하지 않으며, 모든 요청은 독립적으로 처리됩니다.
  3. 캐시 처리 가능 – 응답에 캐시 가능 여부를 명시하여 클라이언트가 데이터를 효율적으로 재사용할 수 있습니다.
  4. 계층화된 시스템 – 클라이언트는 중간 계층(프록시, 게이트웨이 등)을 통해 서버에 접근할 수 있으며, 각 계층은 독립적으로 동작합니다.
  5. 인터페이스 일관성 (Uniform Interface) – 모든 리소스는 일관된 방식(URI, HTTP 메서드 등)으로 접근되어야 하며, REST의 핵심 특징입니다.
  6. 코드 온 디맨드 (선택적) – 클라이언트는 서버로부터 실행 가능한 코드를 전송받아 동적으로 기능을 확장할 수 있습니다 (예: JavaScript).


🧱 REST API의 구성 요소

  • 자원(Resource): URI로 식별되는 객체 (예: /users, /posts/1)
  • 메서드(Method): HTTP 메서드를 통해 자원에 대한 행위 지정
  • 표현(Representation): 자원의 데이터 형식 (JSON, XML 등)
  • 상태 코드(Status Code): 요청 처리 결과를 나타냄

📌 HTTP 메서드 매핑

REST API에서의 HTTP 메서드 사용
메서드 의미 예시
GET 리소스 조회 GET /users/1
POST 리소스 생성 POST /users
PUT 리소스 전체 수정 PUT /users/1
PATCH 리소스 일부 수정 PATCH /users/1
DELETE 리소스 삭제 DELETE /users/1

✅ REST API의 장점

  • URI와 HTTP 메서드만으로도 의미가 명확하여 가독성일관성이 좋음
  • 표준 HTTP 기능 활용 (캐시, 상태 코드 등)
  • 클라이언트와 서버의 역할 분리 가능
  • 확장성과 유지보수가 뛰어남

⚠️ REST API 주의사항

  • URI에는 동사 대신 명사를 사용해야 함 (예: /users OK, /getUser는 지양)
  • 자원의 관계를 계층 구조 URI로 표현 (예: /posts/10/comments)
  • 메서드의 의미와 일치하는 동작을 구현해야 함 (예: 삭제는 DELETE로 처리)

📘 예시: 사용자 API

REST API 설계 예시: 사용자(User)
동작 URI 메서드
사용자 목록 조회 /users GET
사용자 등록 /users POST
특정 사용자 조회 /users/1 GET
사용자 정보 수정 /users/1 PUT 또는 PATCH
사용자 삭제 /users/1 DELETE