REST API: 두 판 사이의 차이
기술노트
편집 요약 없음 |
편집 요약 없음 |
||
(같은 사용자의 중간 판 하나는 보이지 않습니다) | |||
1번째 줄: | 1번째 줄: | ||
== | == 🔍 REST 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" | ||
|+ ''' | |+ '''REST API에서의 HTTP 메서드 사용''' | ||
! | ! 메서드 !! 의미 !! 예시 | ||
|- | |- | ||
| | | GET || 리소스 조회 || <code>GET /users/1</code> | ||
|- | |- | ||
| | | POST || 리소스 생성 || <code>POST /users</code> | ||
|- | |- | ||
| | | PUT || 리소스 전체 수정 || <code>PUT /users/1</code> | ||
|- | |- | ||
| | | PATCH || 리소스 일부 수정 || <code>PATCH /users/1</code> | ||
|- | |- | ||
| | | DELETE || 리소스 삭제 || <code>DELETE /users/1</code> | ||
|} | |} | ||
=== ✅ REST API의 장점 === | |||
* URI와 HTTP 메서드만으로도 의미가 명확하여 '''가독성'''과 '''일관성'''이 좋음 | |||
* '''표준 HTTP 기능 활용''' (캐시, 상태 코드 등) | |||
* '''클라이언트와 서버의 역할 분리''' 가능 | |||
* 확장성과 유지보수가 뛰어남 | |||
=== ⚠️ REST API 주의사항 === | |||
* URI에는 '''동사 대신 명사'''를 사용해야 함 (예: <code>/users</code> OK, <code>/getUser</code>는 지양) | |||
* 자원의 관계를 '''계층 구조 URI'''로 표현 (예: <code>/posts/10/comments</code>) | |||
* 메서드의 의미와 일치하는 동작을 구현해야 함 (예: 삭제는 DELETE로 처리) | |||
== | === 📘 예시: 사용자 API === | ||
{| class="wikitable" | {| class="wikitable" | ||
|+ ''' | |+ '''REST API 설계 예시: 사용자(User)''' | ||
! | ! 동작 !! URI !! 메서드 | ||
|- | |||
| 사용자 목록 조회 || <code>/users</code> || GET | |||
|- | |||
| 사용자 등록 || <code>/users</code> || POST | |||
|- | |||
| 특정 사용자 조회 || <code>/users/1</code> || GET | |||
|- | |- | ||
| | | 사용자 정보 수정 || <code>/users/1</code> || PUT 또는 PATCH | ||
|- | |- | ||
| | | 사용자 삭제 || <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가지 제약 조건을 따릅니다:
- 클라이언트-서버 구조 – 클라이언트와 서버의 책임을 명확히 분리하여 역할 독립성과 확장성을 확보합니다.
- 무상태성 (Stateless) – 요청 간 서버에 클라이언트 상태를 저장하지 않으며, 모든 요청은 독립적으로 처리됩니다.
- 캐시 처리 가능 – 응답에 캐시 가능 여부를 명시하여 클라이언트가 데이터를 효율적으로 재사용할 수 있습니다.
- 계층화된 시스템 – 클라이언트는 중간 계층(프록시, 게이트웨이 등)을 통해 서버에 접근할 수 있으며, 각 계층은 독립적으로 동작합니다.
- 인터페이스 일관성 (Uniform Interface) – 모든 리소스는 일관된 방식(URI, HTTP 메서드 등)으로 접근되어야 하며, REST의 핵심 특징입니다.
- 코드 온 디맨드 (선택적) – 클라이언트는 서버로부터 실행 가능한 코드를 전송받아 동적으로 기능을 확장할 수 있습니다 (예: JavaScript).
🧱 REST API의 구성 요소
- 자원(Resource): URI로 식별되는 객체 (예:
/users
,/posts/1
) - 메서드(Method): HTTP 메서드를 통해 자원에 대한 행위 지정
- 표현(Representation): 자원의 데이터 형식 (JSON, XML 등)
- 상태 코드(Status Code): 요청 처리 결과를 나타냄
📌 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
동작 | URI | 메서드 |
---|---|---|
사용자 목록 조회 | /users |
GET |
사용자 등록 | /users |
POST |
특정 사용자 조회 | /users/1 |
GET |
사용자 정보 수정 | /users/1 |
PUT 또는 PATCH |
사용자 삭제 | /users/1 |
DELETE |