REST API: 두 판 사이의 차이

기술노트
(컴퓨터 과학 용어 정리 - REST API 추가)
 
편집 요약 없음
1번째 줄: 1번째 줄:
==== REST API ====
== 🔁 RESTful API vs 비RESTful API 비교 ==


----
RESTful API는 REST 원칙(자원 중심 URI, HTTP 메서드의 의미, 상태 코드 사용 등)을 따르는 반면, 비RESTful API는 이를 지키지 않아 구조적으로 일관성이 떨어지고 유지보수가 어렵습니다.


REST : 웹 (HTTP) 의 장점을 활용한 아키텍쳐
=== 📊 비교 표 ===


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


* REST의 요소
---


  * Method
== ❌ 비RESTful API의 문제점 ==


    | Method | 의미  | Idempotent |
* 동작의 의미가 URI에 노출되어 직관성이 떨어짐
    | ------ | ------ | ---------- |
* 클라이언트가 기능을 추측해야 하며, API 문서화가 어려움
    | POST  | Create | No        |
* HTTP의 기능을 활용하지 못함 (상태 코드, 캐시, 멱등성 등)
    | GET    | Select | Yes        |
* 자동화 도구(Swagger, Postman 등)와의 호환성 저하
    | PUT    | Update | Yes        |
    | DELETE | Delete | Yes        |


    > Idempotent : 한 번 수행하냐, 여러 번 수행했을 때 결과가 같나?
---


    <br>
== ✅ RESTful API의 장점 ==


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


    * http://myweb/users와 같은 URI
---
    * 모든 것을 Resource (명사)로 표현하고, 세부 Resource에는 id를 붙임


    <br>
== 🧪 실전 예시 ==


  * Message
=== 사용자 삭제 요청 ===


    * 메시지 포맷이 존재
{| class="wikitable"
 
|+ '''RESTful vs 비RESTful 예시'''
      : JSON, XML 과 같은 형태가 있음 (최근에는 JSON 을 씀)
! 방식 !! URI !! 메서드 !! 설명
 
|-
      <syntaxhighlight>text
| 비RESTful || <code>/deleteUser?id=5</code> || POST || URI에 동사 사용, HTTP 메서드 고정
      HTTP POST, http://myweb/users/
|-
      {
| RESTful || <code>/users/5</code> || DELETE || 자원과 동작 분리, 명확한 표현
      "users" : {
|}
      "name" : "terry"
      }
      }
      </syntaxhighlight>
 
    <br>
 
* 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:35 판

🔁 RESTful API vs 비RESTful API 비교

RESTful API는 REST 원칙(자원 중심 URI, HTTP 메서드의 의미, 상태 코드 사용 등)을 따르는 반면, 비RESTful API는 이를 지키지 않아 구조적으로 일관성이 떨어지고 유지보수가 어렵습니다.

📊 비교 표

RESTful API vs 비RESTful API
구분 비RESTful API RESTful API 설명
URI 설계 /getUser?id=1 /users/1 REST는 자원 중심 URI 사용, 동사는 피함
HTTP 메서드 POST /deleteUser DELETE /users/1 메서드 자체가 동작을 의미
리소스 명 /userlist, /createUser /users 복수형 자원 명 사용
상태 코드 항상 200 OK 201, 204, 404 클라이언트가 처리 결과를 정확히 알 수 있음
동작 전달 방식 /do?action=delete&id=1 DELETE /users/1 REST는 메서드+URI로 동작 구분
관계 표현 /getCommentsByPostId?id=10 /posts/10/comments URI 계층 구조로 관계 표현

---

❌ 비RESTful API의 문제점

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

---

✅ RESTful API의 장점

  • 표준화된 HTTP 메서드 활용 (GET, POST, PUT, DELETE)
  • 자원 중심 URI 설계 (예: /users/1/orders)
  • 명확한 상태 코드 제공 → 에러 처리 용이
  • 확장성 우수 → 기능 추가 및 구조 변경이 유연함
  • API 문서화 및 테스트 도구와 호환 우수

---

🧪 실전 예시

사용자 삭제 요청

RESTful vs 비RESTful 예시
방식 URI 메서드 설명
비RESTful /deleteUser?id=5 POST URI에 동사 사용, HTTP 메서드 고정
RESTful /users/5 DELETE 자원과 동작 분리, 명확한 표현