REST API

이민석·2022년 3월 10일

CS

목록 보기

6/7

REST의 탄생 배경과 의미

REST API는 2000년에 HTTP를 잘 활용하지 못한다고 생각한 로이 필딩이 웹을 장점을 살릴 수 있는 아키텍쳐인 REST를 탄생시켰습니다. 이러한 탄생의 배경에는, 단순 브라우저만 사용하는 것이 아닌 다양한 앱의 탄생이 있습니다.

웹브라우저만 사용되던 과거와 달리 현재는 웹/앱 앱에서도 IOS/Android 등 다양한 환경과 통신해야 하기 때문에 각각 다른 API를 작성하는 것은 시간과 자본의 낭비가 발생합니다. 그러므로 범용성을 가진 서버를 디자인의 수요가 생겼습니다.

하지만, 획일화된 Client side를 사용하지 않는 만큼 표준을 정확히 정해야 합니다.
표준을 지키지 않으면 다양한 Client side에 범용적으로 사용할 수 없으며 개발 속도 저하를 발생시킵니다.

REST의 구성

자원

행위

REST는 HTTP의 네가지 Method만을 사용합니다.
- C.R.U.D ( POST, GET, PUT, DELETE )
C.R.U.D Method를 사용할 때 멱등성(idemponent)에 대해서도 알아봅시다.
- 멱등성이란, 연산의 한 성질을 말하며, 여러 번 연산해도 결과값 변화가 없는 성질을 말한다. C.R.U.D 중에 Create(POST)는 멱등성이 적용되지 않습니다.
- GET 메소드의 조회수 같은 경우, 예외적으로 멱등성이 적용되지 않습니다. 글자체를 조회하는 기능이지만 조회수 카운터가 올라가는것 때문에 POST를 사용하면, GET메소드의 캐싱기능을 활용할 수 없습니다. 그러므로 GET을 사용해서 조회하되, HEADER로 조회수를 보내야 합니다.

표현

Client / Server 구조

클라이언트와 서버를 나누어 처리합니다. 공통 데이터가 많은 서버에서 여러 기능을 담당하는 클라이언트에 필요한 데이터만 분배하는 구조가 가능합니다. 위의 탄생 배경에서 말했듯이 웹,앱 등 다양한 환경과 통신해야 하므로, REST API의 구조가 적합합니다.

무상태성(Stateless)

서버는 클라이언트의 상태에 영향을 주지 않습니다. 서로의 영역에서 필요한 기능을 담당하기 때문에, 한 번의 요청에 필요한 정보를 모두 받습니다. 서버는 클라이언트의 요청에 대한 응답만 하고, 클라이언트는 서버에게 응답받은 정보로 처리합니다.

캐시 처리 가능(Cashable)

HTTP의 웹표준을 그대로 사용하므로 캐시 기능을 사용할 수 있습니다. 클라이언트가 서버에 요청을 보낼 때 이전에 캐싱된 데이터가 존재한다면 서버에 요청을 보내지 않고 클라이언트에서 처리합니다.

계층 시스템(Layered System)

클라이언트와 서버 사이에 프록시, 로드밸런서 또는 보안을 위한 중간 서버가 존재할 수 있습니다. 클라이언트 입장에서는 어떤 서버가 존재하는지 모르므로 직접적인 통신에만 신경 써주면 됩니다.

유니폼 인터페이스

REST는 모두의 편의를 위해 형태에 대한 일정한 제약을 가지고 있습니다.
Resource identification in requests
클라이언트가 요청할 때 필요한 정보는 리소스에 담아서 보내고, 서버는 JSON, XML와 같은 형태로 요청에 적합한 정보를 응답합니다.
Resource manipulation through representations
클라이언트가 어떤 정보나 리소스의 상징이나 표현만 가지고 있더라도 이를 이용하여 실제 리소스의 상태를 변경시킬 수 있습니다. (URL과 API설계로 인함)
Self-descriptive messages
각각의 메시지는 어떤 식으로 처리하면 되는지에 대한 정보를 담고 있습니다. 예를 들어, 어떤 종류의 에러가 발생했고 필요한 요청이 무엇인지를 특정할 수 있습니다.

[출처]

오늘은 무엇을 배울까