Post

[CS] REST? RESTful?

Posted
REST
REST
By yeeun426
8 min read
[CS] REST? RESTful?

유레카 백엔드 수업 때 궁금했던 부분이 생겨서 정리해본다 !

궁금했던 해당 수업 스터디 노트
[Day33] 쇼핑몰 실습 - 장바구니, Restful

나는 백엔드가 아니라 rest와 restful의 차이가 뭔지에 대해 잘 모르겠어서 제대로 공부하려한다.

REST(REpresentational State Transfer) = 설계 철학 / 디자인 가이드

  • 웹 서비스가 어떻게 동작해야 하는지에 대한 아키텍처 스타일(설계 원칙)
    • 즉, 자원을 이름으로 구분해, 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미
  • 어떤 자원에 대해 CRUD 연산을 수행하기 위해 URI(Resource)로 GET, POST 등의 방식(Method)을 사용하여 요청을 보내며, 요청을 위한 자원은 특정한 형태(Representation of Resource)로 표현된다.

URI 와 URL의 차이점?
URL은 Uniform Resource Locator로 인터넷 상 자원의 위치를 의미합니다.반면 URI는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로,URI는 URL을 포함하게 됩니다. URI가 URL보다 포괄적인 범위라고 할 수 있습니다.

RESTful API

REST 원칙을 잘 지키며 설계된 API

❓ 우리는 왜 RESTful API를 만드는 것일까?

  • RESTful APIs 개발하는 가장 큰 이유는 Client Side를 정형화된 플랫폼이 아닌 모바일, PC, 어플리케이션 등 플랫폼에 제약을 두지 않는 것을 목표로 했기 때문 !
  • 메시지 기반, XML, JSON과 같은 Client에서 바로 객체로 치환 가능한 형태의 데이터 통신을 지향하게 되면서 Server와 Client의 역할을 분리하게 되었다.

이런 변화를 겪으면서 필요해진 것은 HTTP 표준 규약을 지키면서 API를 만드는 것

CRUD - HTTP Method

HTTP MethodURI 예시설명
GET/products전체 상품 조회
GET/products/{id}특정 상품 조회
POST/cart장바구니에 상품 추가
PUT/cart/{id}장바구니 상품 수정
DELETE/cart/{id}장바구니 상품 삭제

🎯 REST API vs RESTful API 차이

1. URI 설계 방식 (자원 중심 vs 동작 중심)

REST APIRESTful API
/getUserInfo 처럼 동사 기반 URI도 사용/users/1 처럼 명사 중심 URI 사용
URI에 동작을 표현하기도 함HTTP 메서드(GET, POST 등)로 동작 표현

💡 RESTful은 URI는 자원만 표현, 행위는 HTTP 메서드로 표현해야 한다.

예를 들어:

1
2
3
4

GET /users/1       ← RESTful (유저 1 조회)
POST /users        ← RESTful (유저 생성)
PUT /users/1       ← RESTful (유저 수정)
DELETE /users/1    ← RESTful (유저 삭제)

반면:

1

GET /getUserInfo?id=1   ← RESTful ❌

2. REST 원칙 준수 여부

REST APIRESTful API
REST 원칙을 부분적으로만 따름REST의 6가지 제약조건을 엄격히 따름
상태가 있을 수도 있고, URI 구조가 명확하지 않을 수 있음무상태성(stateless), 계층성, 일관성 등 철저하게 지킴

REST 는 권장되는 설계 규칙들(어떻게 만들까)
REST API는 그 철학을 ‘대충’ 따르는 API,
RESTful API는 그 철학을 ‘정확히’ 지킨 API

❓ 그 철학(REST)이 뭔데? (RESTful API가 따라야 할 제약 조건)

Roy Fielding의 논문에서 나온 “아키텍처 스타일 제약 조건”

  1. 클라이언트 / 서버 구조
    • 역할을 분리해서 관리하자 (클라이언트는 UI, 서버는 데이터 처리)
  2. 무상태성 (Stateless)
    • 서버는 클라이언트 상태를 기억하지 말고, 매 요청마다 완전한 정보를 받아야 함
  3. 캐시 처리 가능 (Cacheable)
    • 응답 결과가 같다면 캐시를 활용할 수 있어야 해
  4. 계층화 구조 (Layered System)
    • 서버 여러 단계를 거쳐도 클라이언트는 한 대의 서버처럼 느껴야 함
  5. 유니폼 인터페이스 (Uniform)
    • 누구든 REST API를 보면 바로 이해 가능해야함.
  6. 코드 온 디맨드 (Code on Demand)
    • 필요 시 클라이언트에 코드(JS 등)를 내려줄 수 있음

RESTful API 설계 규칙 (실무에서 REST를 구현하기 위한 실천 가이드)

HATEOAS (Hypermidia As The Engine Of Application State)

기본적으로 요청에 대해 서버는 응답에 데이터만 클라이언트에게 보내는데,
HATEOAS를 사용하면 응답에 데이터뿐만 아니라 해당 데이터와 관련된 요청에 필요한 URI를 응답에 포함하여 반환하며, 이는 REST API를 사용하는 클라이언트가 전적으로 서버와 동적인 상호작용이 가능하도록 해준다.

↩️ HATEOAS 적용 전

1
2
3
4

{
  "orderId": 123,
  "status": "processing"
}

↪️ HATEOAS 적용

1
2
3
4
5
6
7
8
9
10
11
12

{
  "orderId": 123,
  "status": "processing",
  "_links": {
    "cancel": {
      "href": "/orders/123/cancel"
    },
    "track": {
      "href": "/orders/123/track"
    }
  }
}

클라이언트는 응답만 보고도:

  • “이 주문은 /orders/123/cancel을 호출하면 취소되겠구나!”
  • “배송 조회는 /orders/123/track을 호출하면 되겠네!” 라고 API 문서를 보지 않고도 자동으로 행동을 결정할 수 있다.

아무튼 다른건 다 까먹어도 기억해야 하는건 !
“REST API는 URI는 정보의 자원만 표현하고, 자원의 행위는 HTTP Method를 통해 명시한다”

Reference

이 포스트는 아래 게시글의 정보 및 이미지가 사용되었습니다.

END

Web, CS
REST REST RESTful
This post is licensed under CC BY 4.0 by the author.