REST API: 두 판 사이의 차이

기술노트
(컴퓨터 과학 용어 정리 - REST API 추가)
 
편집 요약 없음
 
(같은 사용자의 중간 판 2개는 보이지 않습니다)
1번째 줄: 1번째 줄:
==== REST API  ====
== 🔍 REST API란? ==


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


REST : 웹 (HTTP) 의 장점을 활용한 아키텍쳐
=== 🌐 REST란? ===


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


* REST의 요소


  * Method
=== 🧱 REST API의 구성 요소 ===


    | Method | 의미  | Idempotent |
* '''자원(Resource)''': URI로 식별되는 객체 (예: <code>/users</code>, <code>/posts/1</code>)
    | ------ | ------ | ---------- |
* '''메서드(Method)''': HTTP 메서드를 통해 자원에 대한 행위 지정
    | POST  | Create | No        |
* '''표현(Representation)''': 자원의 데이터 형식 (JSON, XML 등)
    | GET    | Select | Yes        |
* '''상태 코드(Status Code)''': 요청 처리 결과를 나타냄
    | PUT    | Update | Yes        |
    | DELETE | Delete | Yes        |


    > Idempotent : 한 번 수행하냐, 여러 번 수행했을 때 결과가 같나?
=== 📌 HTTP 메서드 매핑 ===


    <br>
{| 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>
|}


  * Resource
=== ✅ REST API의 장점 ===


    * http://myweb/users와 같은 URI
* URI와 HTTP 메서드만으로도 의미가 명확하여 '''가독성'''과 '''일관성'''이 좋음
    * 모든 것을 Resource (명사)로 표현하고, 세부 Resource에는 id를 붙임
* '''표준 HTTP 기능 활용''' (캐시, 상태 코드 등)
* '''클라이언트와 서버의 역할 분리''' 가능
* 확장성과 유지보수가 뛰어남


    <br>
=== ⚠️ REST API 주의사항 ===


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


    * 메시지 포맷이 존재
=== 📘 예시: 사용자 API ===


      : JSON, XML 과 같은 형태가 있음 (최근에는 JSON 을 씀)
{| class="wikitable"
 
|+ '''REST API 설계 예시: 사용자(User)'''
      <syntaxhighlight>text
! 동작 !! URI !! 메서드
      HTTP POST, http://myweb/users/
|-
      {
| 사용자 목록 조회 || <code>/users</code> || GET
      "users" : {
|-
      "name" : "terry"
| 사용자 등록 || <code>/users</code> || POST
      }
|-
      }
| 특정 사용자 조회 || <code>/users/1</code> || GET
      </syntaxhighlight>
|-
 
| 사용자 정보 수정 || <code>/users/1</code> || PUT 또는 PATCH
    <br>
|-
 
| 사용자 삭제 || <code>/users/1</code> || DELETE
* REST 특징
|}
 
  * Uniform Interface
 
    * HTTP 표준만 맞는다면, 어떤 기술도 가능한 Interface 스타일
 
      예) REST API 정의를 HTTP + JSON로 하였다면, C, Java, Python, IOS 플랫폼 등 특정 언어나 기술에 종속 받지 않고, 모든 플랫폼에 사용이 가능한 Loosely Coupling 구조
 
    * 포함
      * Self-Descriptive Messages
 
        * API 메시지만 보고, API를 이해할 수 있는 구조 (Resource, Method를 이용해 무슨 행위를 하는지 직관적으로 이해할 수 있음)
 
      * HATEOAS(Hypermedia As The Engine Of Application State)
 
        * Application의 상태(State)는 Hyperlink를 통해 전이되어야 함.
        * 서버는 현재 이용 가능한 다른 작업에 대한 하이퍼링크를 포함하여 응답해야 함.
 
      * Resource Identification In Requests
 
      * Resource Manipulation Through Representations
 
  * Statelessness
 
    * 즉, HTTP Session과 같은 컨텍스트 저장소에 '''<u>상태 정보 저장 안함</u>'''
    * '''<u>Request만 Message로 처리</u>'''하면 되고, 컨텍스트 정보를 신경쓰지 않아도 되므로, '''<u>구현이 단순해짐</u>'''.
 
    * 따라서, REST API 실행중 실패가 발생한 경우, Transaction 복구를 위해 기존의 상태를 저장할 필요가 있다. (POST Method 제외)
 
  * Resource 지향 아키텍쳐 (ROA : Resource Oriented Architecture)
 
    * Resource 기반의 복수형 명사 형태의 정의를 권장.
 
  * Client-Server Architecture
 
  * Cache Ability
 
  * Layered System
 
  * Code On Demand(Optional)

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