REST, REST API, RESTful 이란 ?

mallin·2022년 3월 21일
0

WEB

목록 보기
1/3
post-thumbnail
post-custom-banner

기존에 API 를 설계할 때 이렇게 얘기를 많이 하게 된다.

SY : 저희 REST 하게 설계해야 하지 않나요 ?
SY : 뭔가 RESTful 하지 않은 것 같아요.
SY : REST API 형식에 맞춰서 설계 하는게 좋을 것 같은데 ..

REST, RESTful, REST API ... 홈 ... ?
어떤게 맞는 거고, 어떻게 다른거지 ?? 라는 생각이 들게 되었다.

https://media.giphy.com/media/kPtv3UIPrv36cjxqLs/giphy.gif

오늘은 해당 궁금증을 풀어보기 위해 REST, REST API, RESTful 에 대해서 알아보자.

REST

분산 시스템 설계를 위한 아키텍처 스타일 (제약 조건의 집합)

REST 가 필요한 이유

  1. 분산시스템을 위해서
    다른 모듈 또는 어플리케이션이라고 해도 쉽게 통신 할 수 있다.
  2. WEB 브라우저외의 클라이언트를 위해서
    HTML 이나 이미지를 Response 로 전달해주는게 아니라 요청한 데이터만 깔끔하게 보내주면 되기 때문에 가볍고 유지보수가 쉽다.

REST 구성 요소

자원 + 자원에 대한 행위 + 자원에 대한 행위의 내용

자원 : HTTP URI
- 모든 자원은 고유한 ID가 존재하고, 이 자원은 서버에 존재한다.
- 자원을 구조와 함께 나타내는 구분자
- 식별자라고 간단하게 생각할 수 있다.

자원에 대한 행위 : HTTP Method
- API 의 표현방식

자원에 대한 행위의 내용 : HTTP Message Pay Load

GET /order/#{orderId}/payment

가 있을 때 자원은 /order/#{orderId}/payment, 자원에 대한 행위는 GET가 된다.

REST 특징

  1. Server-Client (서버-클라이언트 구조)
    : Client 와 서버의 역할이 확실히 구분되기 때문에 의존성이 줄어든다.

  2. Stateless(무상태)
    : 작업을 위한 상태정보를 따로 저장하고 관리하지 않음.

  3. Cacheable(캐시 처리 기능)
    : 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용 가능
    : Last-Modified 태그나 E-Tag 를 이용하면 캐싱 구현 가능

  4. Layered System(계층화)
    : 다중 계층으로 구성될 수 있음

  5. Code-On-Demand(optional)
    : 반드시 충족할 필요 X

  6. ⭐️ Uniform Interface
    : 자원은 유일하게 식별가능해야하고, HTTP Method로 표현을 담아야 하고, 메세지는 스스로를 설명(self-descriptive)해야하고, 하이퍼링크를 통해서 애플리케이션의 상태가 전이(HATEOAS)되어야 한다.

self-descriptive 란 ?
메세지가 스스로 설명이 되어야 한다는 것
즉, 메시지의 모든 요소는 메시지만 보고 그 뜻을 알아야 한다는 것

HATEOAS 란 ?
애플리케이션의 상태는 하이퍼링크를 통해서 전이 되어야 한다.

HTTP/1.1 200 OK
Content-Type: text/html

<html>
<head></head>
<body>
 	<h2>잠실역</h2>
	<h4><a href="/subways/1/times"></a>운행정보</h4>
    <h4><a href="/subways/1/details"></a>세부정보</h4>
</body>
<html>

위의 예처럼 잠실역에 대한 정보를 하이퍼 링크를 통해서 알 수 있어야 한다.
JSON 의 경우 Header의 link 를 통해 다음 상태를 표시할 수 있다.

REST API

REST 의 원리를 따르는 API를 의미

REST API 는 개발자 사이에 정의된 규약, 형식일 뿐 반드시 이걸 사용해야한 다는 건 아니다

설계 기본 규칙

  1. URI 는 정보의 자원을 표현해야 한다.
    : 동사보다는 명사를 사용해야 한다.
    : 대문자 보다는 소문자를 사용해야 한다.

  2. 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현한다
    : URI 에 행위가 들어가면 안된다. EX) DELETE /members/1/delete (X)

설계 규칙

  1. 슬래시 구분자(/) 는 계층 관게를 나타내는데 사용한다.
    EX) /school/students

  2. URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
    : 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시를 사용하지 않는다.

  3. 언더바(_) 대신 하이픈(-)을 사용한다.

  4. 파일확장자(jpg, png ...)는 URI 에 포함하지 않는다.

  5. 리소스 간에 연관 관계가 있는 경우 /리소스명/리소스 ID/관계가 있는 다른 리소스명 의 형식으로 나타낸다.

RESTful

REST 의 원리를 따르는 시스템

REST 라는 아키텍처 스타일이 있는 거고, RESTful 은 REST 아키텍처의 원칙을 모두 만족했을 경우를 말한다. 혼용해서 사용하는 경우가 있는데 엄밀하게 따지면 다른 걸 의미한다 ❗️

  • REST 라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어
  • ‘REST API’ 를 제공하는 웹 서비스를 ‘RESTFUL’ 하다고 한다.

Rest vs REST API vs RESTful API

REST 는 분산 시스템 설계를 위한 아키텍처 스타일
REST API 는 REST 를 기반으로 구현한 API
RESTful (API) 는 위의 제약 조건을 모두 만족하는 것

그렇기 때문에 위의 대화에서는 RESTful 이라고 얘기하는게 가장 알맞다

🙇🏼‍♀️ 레퍼런스

[네트워크] REST API란? REST, RESTful이란?
[Network] REST란? REST API란? RESTful이란?
REST API 제대로 알고 사용하기
RESTful에 대해서 설명해주세요.(REST, RESTful, RESTful API 개념 정리)
Self descriptive와 HATEOS / 대부분 못 지키고 있는 REST 제약조건

post-custom-banner

0개의 댓글