"RESTful하게 API를 만들어라" 라고 들었을 때,
RESTful하다는 게 어떤 뜻일지가 궁금해진다.
☞ RESTful하다는 것 = REST한 특징을 지키는 것을 의미한다.
그럼 REST한 특징은 무엇인가?
이번 포스팅은 REST를 알아보며 RESTful API를 이해하는 것이 목적이다.
1. REST (Representational State Transfer) ?
먼저, REST는 프로토콜이 아니다.
REST는 웹에 있는 기존 기술(GET, POST 등..)과 HTTP 프로토콜을 그대로 활용하는 아키텍처 스타일일 뿐이다.
조금 더 나아가서 웹과 관련하여 존재하는 모든 자원(이미지, 동영상, DB 데이터 등..)에 고유한 URI를 부여하는 자원을 정의하고 자원에 대한 주소를 지정하는 방법론이라는 측면에서
REST는 HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 자원(Resource: URI)과 행위(Verb: HTTP Method)로 표현하여 특정한 형태(Representations)로 전달하는 방식'이라고도 정의할 수 있다.
정의에 사용된 자원, 행위, 형태는 REST를 이루는 구성이라고 할 수 있다.
1) REST 구성
-
자원 (Resource)
URI라고도 한다.
서버는 Unique한 ID를 가지는 Resource(URI)를 가지고 있다.URL와 URI의 차이
URL (Uniform Resource Local) : 인터넷 상에서 자원의 위치.
URI (Uniform Resource Identifier) : 인터넷 상에서 자원을 식별하기 위한 것.
즉, URI가 URL보다 큰 개념으로 URI는 URL을 포함한다. -
행위 (Verb)
HTTP Method라고 할 수 있다.
일반적으로HTTP Method에는 GET, POST, PUT, PATCH, DELETE 등이 있다.
(1) GET : 데이터 조회 (READ)
(2) POST : 데이터 생성 (CREATE)
(3) PUT : 데이터 수정 (UPDATE)
(4) PATCH : 데이터의 부분적인 수정 (Partitional UPDATE)
(5) DELETE : 데이터 삭제 (DELETE)여기서, PUT과 PATCH의 차이는 아래의 예제를 보면서 이해하자.
PUT은 모든 데이터를 갈아치워버린다. 이때, 입력해주지 않은 키 에 대한 값은 null 처리.
PATCH는 입력하지 않은 키는 그대로 두고, 입력한 키에 대한 값만 변경한다.
-
표현 (Representations)
클라이언트와 서버가 데이터를 주고받는 형태이며, JSON, XML, TEXT, RSS 등이 있다.
일반적으로 JSON을 가장 많이 쓰는 추세이다.
2) REST는 왜 대두되었을까?
애플리케이션의 분리/통합과 다양한 클라이언트의 등장이 원인이라고 할 수 있다.
점점 서비스는 커지고 애플리케이션의 복잡도는 증가한다.
이에 따라 애플리케이션을 분리하고 통합하는 것은 중요한 이슈가 되었고, MSA와 REST가 대두되기 시작했다.
또한, 모바일과 PC 및 다양한 장치의 등장에 따라 하나의 서버가 다양한 장치(여기서는 클라이언트)에 대응하기 위해 REST의 일관된 인터페이스라는 특징이 REST를 대두하게 만들었다.
3) REST는 어떤 특징이 있을까?
※ RESTful API가 되기 위해서는 아래의 특징들이 지켜져야 한다.
-
Uniform Interface (균일한 or 일관된 인터페이스)
Uniform Interface라는 특징은 RESTful 시스템 설계의 기본이다.
아키텍쳐를 단순화하고 분리하여, 각 부분이 독립적으로 발전 할 수 있도록 하는데 이때Uniform Interface의 네가지 제약은 아래와 같다.
(1) Resource identification in requests
(2) Resource manipulation through representations
(3) Self-descriptive messages (자체적인 설명이 되는 메시지)
각 메시지는 메시지 처리 방법을 설명하기에 충분한 정보가 포함되어 있어야 한다.
(4) Hypermedia as the engine of application state -
Stateless (무상태성)
상태정보를 따로 관리하지 않고 단순히 API 서버로 들어오는 요청만을 처리하면 된다.
이는 서비스의 자유도가 높아지게 해주며, API 서버에 불필요한 정보를 관리하지 않게 되므로 구현에도 용이하다. -
Cacheable (캐시가능)
HTTP 기존의 웹 표준을 사용하므로 HTTP 프로토콜 기반의 로드밸런서(mod_proxy), SLL, 캐싱 기능을 적용 가능. -
Client-Server Architecture (서버-클라이언트 구조)
REST API에서 자원을 가지고 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트에 해당한다.
일반적으로 서버는 API를 제공하고, 클라이언트는 그 정보를 사용하는 다른 역할(사용자 인증, 세션 관리, 로그인 정보 관리 등..)을 함으로써 역할의 구분을 통해 의존성을 줄인다. -
Layered System (계층 구조)
클라이언트는 서버와 직접 통신하는지, 서버 앞의 중간 서버와 통신하는지 알 수 없다.
'클라이언트 요청 > Rest API (데이터 조회)'처럼 사용되는 것처럼 보일 수 있다.
하지만 '클라이언트 요청 > Rest API (프록시 서버 > 로드 밸런싱 > 암호화 > 데이터 조회)'처럼 더 많은 다양한 계층을 거칠 수도 있다.
4) RESTful API를 설계할려면?
※ RESTful한 API를 설계하는 법을 알고 싶다면 이 포스팅을 참고한다.
5) RESTful API를 사용하면 뭐가 좋은지?
위에서 언급한 REST의 특징이 RESTful API의 장점이라고 할 수 있을 것이다.
가장 단순한 장점이라면
잘 만들어진 RESTful API 메시지를 보는 것으로 메시지의 의도를 파악할 수 있다는 것?
Stateless를 통해 Client - Server가 각자의 역할을 충실히 수행할 수 있다는 것?
6) RESTful API의 단점은?
제한적인 HTTP method로 인해 여러가지 기능을 구현하는 데는 제약이 발생할 수 있다.
(사실 어거지로 내부 데이터 포맷의 데이터를 이용해서 구현할 수는 있겠으나, 개발원칙을 어기게 될 가능성이 높아보인다.)
또한, 가장 큰 단점으로 표준이 존재하지 않는 다는 것.
'공식대로 이렇게 만들어라'는 표준이 존재하지 않기 때문에 RESTful API를 사용하는 각 조직의 '약속'에 따라 만들어지게 된다.
생각없이 RESTful API를 만들어 보았던 시절을 생각하면서, 간단하게 RESTful API에 대해 포스팅을 해보았다.
이 밖에, RESTful API를 만들기 위한 설계하기 위하 제공되는 규칙이나, 보안에 관계있는 것들이 있으니 이런 부분은 직접 찾아보는 걸 권장한다.
참고
https://brainbackdoor.tistory.com/53
https://mangkyu.tistory.com/46
https://sanghaklee.tistory.com/57
https://wallees.wordpress.com/2018/04/19/rest-api-%EC%9E%A5%EB%8B%A8%EC%A0%90/
https://papababo.tistory.com/entry/HTTP-METHOD-PUT-vs-PATCH-%EC%B0%A8%EC%9D%B4%EC%A0%90
