REST API 란?

웹 개발을 한다면 한 번쯤은 들어볼 REST API에 대해 정리해보려고합니다. 

이번 글을 정리하면서 대부분의 웹서비스가 REST API를 왜 사용하고 있는지에 대해 알게 되었고  웹 개발자로 일을 하면서

 

REST란?

REST는 "Representational State Transfer"의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미합니다. 

 

"자원"이라는 것이 저는 추상적이라고 느껴져서 구체적인 예시를 들어서 설명하자면 DB로부터 학생의 기본정보를 조회하는 상황을 생각해보겠습니다. 

JSON형식으로 데이터를 조회한다면 학생의 아이디나 시퀀스(기본키로 사용되는 값)를 가지고 학생의 정보를 조회할 것이라고 떠올릴 수 있을 것 같습니다. 

student : {
	name : '홍길동',
    	age : 23,
}

 이렇게 학생의 정보 즉, DB내의 데이터인 자원을 student [name, age] 등으로 표현해 그 상태를 전달하는 것을 의미합니다.  

 

이 예시에서는 JSON을 사용했지만 이외에도 xml을 사용해서 자원의 상태를 표현하는 것도 가능합니다. 

 

잠깐 JSON과 xml에 차이점에 대해 정리하자면

• JSON은 구조를 정의 하기 용이하고 가독성이 뛰어나며 가볍다는 특징이 있습니다.(가볍다는 것은 클라이언트와 서버, 서버와 서버 사이에서 통신할 때 전달하는 패킷에 담기는 내용의 용량이 적다는 것을 의미합니다)
• xml은 json에 비해 가독성이 떨어지고 무겁다는 특징이 있지만 새로운 운영체제나 프로그램, 브라우저등에 상관없이 데이터를 안전하게(데이터의 정합성을 충족하기 용이함) 전송할 수 있습니다.

JSON과 xml의 특징에 부합하는 개발 상황에 따라서 적절하게 사용하는 것이 중요한 것 같습니다.(JSON을 많이 쓰니까 JSON으로 하면 될 거야!라고 생각하는 것은 좋은 사고방식이 아니라는 것을 깨닫게 되었습니다) 

 

REST를 사용하는 이유

다양한 클라이언트 등장

 

클라이언트라는 것은 대게 "서버에 요청하는 역할을 담당"으로 이해되고 있습니다. 즉 서버에 요청을 담당하는 녀석들이 다양해졌다는 건(안드로이드, 아이폰, 다양한 브라우저들의 등장) 그만큼 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 연구할 필요성이 대두되었다는 것을 의미합니다. REST는 HTTP 표준 프로토콜을 따르고 있기 때문에 멀티 플랫폼 환경에 대응하기 용이합니다. 

 

 

REST 구성요소

1. 자원(Resource) : URI
   • 자원을 요청하기 위해서는 그 자원을 유일하게 식별할 수 있어야 합니다. 예를 들어 "특정 학생의 정보"라는 자원을 얻기 위해서는 그 자원을 유일하게 식별할 수 있는 키가 있어야 하는데 URI가 그 역할을 합니다.
   • 예를 들어 /student/1는 URI는 1번 학생의 정보를 조회하는 키로써 역할을 한다고 생각하면 될 것 같습니다. 즉, /student/1이라는 1번 학생의 정보를 조회하는 유일 키입니다.  
2. 행위(Verb) : Http Method
   • REST는 HTTP 표준 프로토콜의 인프라를 그대로 사용하기 때문에 HTTP 프로토콜의 Method를 사용합니다. 
   • HTTP 프로토콜의 Method는 GET/POST/PUT/DELETE 4가지의 종류만 지원하고 있습니다. 
3. 표현(Representation of Resource)
   • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 표현으로 나타낼 수 있는데 일반적으로 JSON, XML로 표현하고 있습니다.

 

REST의 6가지 기본 원칙과 RESTful의 의미

RESTful 하다는 의미는 REST의 여섯 가지 기본 원칙이 있는데 이 가이드를 준수한 인터페이스에 대해서는 RESTful 하다고 표현합니다.

 

그럼 REST의 6가지 기본 규칙은 다음과 같습니다.

 

1. client - server 구조
   • client와 서버는 서로 독립적이어야 하며, client는 오직 URI 리소스만 알아야 합니다. client와 server의 인터페이스가 변경되지 않는 한 이 둘은 독립적으로 개발되거나 대체될 수 있게 유지해야 합니다.
2. Stateless (무상 태성)
   • HTTP 프로토콜은 Stateless Protocol의 특징을 갖는데 REST 역시 마찬가지입니다. 
   • Stateless protocol의 특징은 서버는 각각의 요청을 완전히 별개의 것으로 인식하고 처리해야 하는데 이 말인즉슨, 이전 요청이 다음 요청의 처리에 연관되어서는 안 된다는 말입니다. 
   • 서버의 처리 방식에 일관성을 부여하고 Client의 context(세션과 쿠키와 같은 정보)를 신경 쓰지 않아도 되기에 부담이 줄어들며  서비스의 자유도가 높아진다는 특징이 있습니다.
3. Cacheable (캐시 처리 가능)
   • 서버는 Response cache-control이 헤더에 특정 요청이 캐싱이 가능한 지에 대한 여부를 제공해야 합니다. 
4. Uniform Interface (일관된 인터페이스)
   • 일관된 인터페이스를 얻기 위한 4가지 인터페이스 규칙
     • 요청 시 개별 자원을 식별할 수 있어야 한다.
     • 어떤 자원에 대해 작업하기 위한 적절한 표현과 메타데이터를 충분히 갖추고 있다면 서버는 해당 자원을 변경, 삭제할 수 있는 정보를 가지고 있다는 의미이다.
     • 자신을 어떻게 처리해야 하는지 정보를 포함해야 한다.
     • 단순히 결과뿐만이 아니라 결과에 대한 정보를 포함해야 한다.
5. Layered System (다중 계층)
   • REST는 다중 계층을 허용해야 한다. (예를 들어 API 서버/ DB 서버/ 인증 서버를 따로 둘 수 있어야 한다.)
   • 각 레이어는 자기와 통신하는 컴포넌트 외 레이어에 대해서는 정보를 얻을 수 없다. 
   • 클라이언트는 REST 서버와만 상호작용할 뿐 REST가 상호작용하는 레이어나 그 외 중간 레이어들을 직접 요청할 수 없으며 상호작용 또한 볼 수 없다.
6. Code on demand 
   • code on demand는 client에 보내는 데이터를 바로 실행 가능한 코드를 보내서 client에서 실행하는 것을 의미한다.
   • 이를 통해 client가 사전에 구현해야 하는 기능의 수를 줄여 간소화할 수 있지만 가독성이 떨어질 수 있다.

 

RESTful 한 API는 구현하는 목적이 성능 향상에 있지 않습니다! 일반적으로 API의 이해도와 호환성을 높이는 것이 주 동기라는 것을 기억하고 있으면 좋을 것 같습니다.

 

 

출처 :

• https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
• https://prohannah.tistory.com/156