REST API 이해하기!

(이전 블로그에 2019년 10월 28일에 작성된 글을 옮겨 편집한 글입니다)

과거에는 브라우저가 웹서버에 웹페이지를 요청하여 클라이언트를 제공하여 웹페이지가 작동하였다.

하지만 최근에는 SPA(Signle-Page-Application)를 이용하여 클라이언트를 구현하며, 클라이언트를 서버와 분리하여 클라이언트 로직을 구분한다. 또한 서버에 API를 요청하므로써 웹 어플리케이션을 개발한다.

이때 서버의 API를 구성할 때, 아무렇게 만드는 것이 아니라 규격이 필요한데, 컨벤션이라고도 할 수 있는 일정한 규칙이 필요하다.

REST API 란

REST API에 REST는 REpresentational State Transfer(대표적인 상태 전달)의 약자로 소프트웨어 프로그램 아키텍처의 한 형식인데, "웹에 존재하는 모든 자원(이미지, 동영상, DB 자원)에 고유한 URI를 부여해 활용"하는 것으로, 자원을 정의하고 자원에 대한 주소를 지정하는 방법론을 의미한다.

따라서 Restful API는 REST 특징을 지키면서 API를 제공하는 것을 의미한다.

REST API 성숙도 모델

Martin Fowler라는 사람이 2010년 제안한 Richardson Maturity Model (Richardson 성숙도 모델)에 의하면 총 4단계로 REST API의 요소를 구성하고 있다.

REST 구성

REST API는 다음의 구성으로 이루어져있다.

자원 (Resource) - URL
행위 (Verb) - Http method
표현 (Representations)

REST 특징

REST 아키택처를 이용하여 API를 설계하였을 때 아래와 같은 이점을 가진다.

1. 클라이언트/서버 구조

클라이언트는 유저와 관련된 처리를, 서버는 REST api를 제공함으로써 각각의 역활이 확실하게 구분되고 일관적인 인터페이스로 분리되어 작동할 수 있게 한다.

2. 무상태성 (Stateless)

REST는 HTTP의 특성을 이용하기 때문에 무상태성을 갖는다. 즉 서버에서 어떤 작업을 하기 위해 상태정보를 기억할 필요가 없고 들어온 요청에 대해 처리만 해주면 되기 때문에 구현이 쉽고 단순해진다.

3. 캐시 처리 가능(Cacheable)

HTTP라는 기존 웹표준을 사용하는 REST의 특징 덕분에 기본 웹에서 사용하는 인프라를 그대로 사용 가능하다.

4. 계층화(Layered System)

클라이언트와 서버가 분리되어 있기 때문에 중간에 프록시 서버, 암호화 계층등 중간매체를 사용할 수 있어 자유도가 높다.

5. 유니폼 인터페이스(Uniform Interface)

Uniform Interface는 Http 표준에만 따른다면 모든 플랫폼에서 사용이 가능하며, URI로 지정한 리소스에 대한 조작을 가능하게 하는 아키텍처 스타일을 말한다.
Uniform Interface의 제약조건
1. Self-descriptive messages:
  - 메시지는 스스로 설명해야한다.
  - REST API 메세지만으로 그 요청이 어떤 행위를 하는지 알 수 있어야한다.
2. HATEOAS(Hypermedia As The Engine Of Application State):
  - 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야한다.
  - 이 제약조건이 있는 이유는 기존에는 서버와 클라이언트가 각각 독립적으로 진화하는데, 서버의 기능이 변경되어도 클라이언트를 업데이트 할 필요를 없애기 위함이다.
  - REST를 만들게 된 계기가 바로 그것이기 때문이다. "How do I improve HTTP without breaking the Web."
  - 쉽게 설명하자면 특정 페이지에서 API가 호출되고 이후에 할 수 있는 동작들에 필요한 API 정보를 함께 제공하여, 클라이언트는 해당 정보만을 참조하여 API를 호출하도록 한다. 그렇게 되면 서버의 변경이 생겨도 클라이언트는 깨지지 않는다.

REST API를 설계하는 법

1. URL는 정보의 자원을 표현한다.

제목 대로 URL는 정보의 자원을 표현해야하기 때문에 설계 할때 몇 가지 지켜야 할 것들이 있다.

소문자를 사용한다.
- 대소문자에 차이를 두기 떄문에(foo.com과 FOo.com은 서로 다르다) 혼란을 줄 수 있기 때문에 지양하는 것이 좋다.
하이픈( - )을 사용한다.
확장자를 사용하지 않는다.
- 아래와 같이 했을 때, 확장자에 때른 url을 만들어야 하기 떄문에 비효울적일 수 있다.
  `http://foo.com/world.txt`, `http://foo.com/world.png`
밑줄( _ )은 사용하지 않는다.

2. 자원에 대한 행위는 HTTP Method로 표현한다

아래가 대표적으로 사용하는 4가지 Mehtod이다.

HTTP Method	역할
GET	리소스를 조회한다.
POST	리소스를 생성한다.
PUT	리소스를 수정한다.
DELETE	리소스를 삭제한다.

예를 들어 글을 수정하기 위해선 아래와 같이 할 수 있다.

POST /posts/put/:id (X)
POST /posts/update/:id (X)

PUT /posts/:id (O)

참고자료

'Programming > Web' 카테고리의 다른 글

CORS 이슈 이해하고 해결하기! (1)	2025.01.27