RESTful API 개념 정리

일단 API 라는 단어는 많이 들어보셨겠지만 간단하게 정의만 집고 넘어가겠습니다.

API

애플리케이션 소프트웨어를 구축하고 통합하기 위한 정의 및 프로토콜 세트로,
애플리케이션 프로그래밍 인터페이스(Application Programming Interface)를 나타냅니다.
API를 사용하면 구현 방식을 알지 못해도 제품 또는 서비스가 서로 커뮤니케이션할 수 있으며
애플리케이션 개발을 간소화하여 시간과 비용을 절약할 수 있습니다. 

출처 : https://www.redhat.com/ko/topics/api/what-are-application-programming-interfaces

 

API는 알겠는데 그럼 RESTful 은 뭘까요?

REST는 Representational State Transfer 의 줄임말로 HTTP의 subset을 사용하는 소프트웨어의 아키텍처 스타일입니다. 

REST 아키텍처는 6가지 조건을 가지고 있는데요.

---

1. 클라이언트, 서버, 리소스로 구성된 클라이언트-서버 아키텍처가 필요합니다.

- 클라이언트를 서버에서 분리한 아키텍처 형태로 클라이언트가 리소스를 요청하면 서버에서 내주는 형식으로 각 부분을 독립적으로 개선될 수 있는 여지를 만들어 둡니다.

2. 요청이 통과하는 서버에 클라이언트 콘텐츠가 저장되지 않는 스테이트리스(stateless) 클라이언트-서버 커뮤니케이션이 필요합니다. 대신 세션의 상태에 대한 정보가 클라이언트에 저장됩니다.

- 클라이언트가 서버에게 요청을 할때는 그 메시지에 요청에 필요한 모든 메시지가 들어있어야 합니다. 예전에 저장했던 클라이언트에 대한 정보등을 써서는 안됩니다. 만약 이전에 정보를 저장했고 사용한다면 그것은 stateful 이 됩니다.

3. 일부 클라이언트-서버 간 상호 작용의 필요성을 제거할 캐시 가능 데이터가 필요합니다.

-  응답을 캐싱하여 재사용 할 수 있어야 합니다.  이는 클라이언트와 서버간의 상호 작용을 간소화하는 캐시 데이터가 됩니다. 

4. 애플리케이션 요구 사항별로 다른 형식이 아닌, 표준화된 형식으로 정보를 전송할 수 있도록 구성 요소 간 통합된 인터페이스가 필요합니다. 

- 요구 사항마다 인터페이스가 다르다면 요구 사항이 늘어날때마다 고려해야될 것이 많아집니다. 이러한 것을 방지 할 수 있도록 전체적인 아키텍처를 잘 파악할 수 있는 일관된 인터페이스가 필요합니다.

5. 클라이언트-서버 간의 상호 작용을 계층적으로 조정할 수 있도록 계층화된 시스템 제약이 필요합니다.

-  요청된 정보를 검색하는 데 작동하는 서버를(중간 서버인지, 보통 서버인지) 클라이언트가 볼 수 없도록 만듭니다.

6. 실행 가능한 코드를 전송해 서버가 클라이언트의 기능을 확장할 수 있게 해주는 코드 온디맨드가 필요합니다. 단, 가시성이 감소할 수 있으므로 이는 선택적 가이드라인입니다.

- 일반적으로 클라이언트가 요청을 하면 서버에서 처리를 하여 클라이언트가 결과 데이터만 받아오는 형식이지만 필요에 따라 서버가 코드를 보내주어 이를 클라이언트에서 할수 있도록 하는 행위를 말합니다.

---

결국 REST API는 위의 조건을 맞춘 API 라고도 볼 수있지만 일반적인 API와의 차이점은 

차이점은 API는 소스코드들 간 데이터를 주고 받는 반면 Rest(ful) API는 웹의 프로토콜 내에서 동작한다는 점입니다.

REST API를 거쳐 나온 데이터에 예쁜 디자인을 씌우면 우리가 흔히 알고 있는 기록 조회 사이트등이 되는 것 입니다.

 

글쓰며 참조한 글들

[REST API] REST API에 관하여_6가지 제약조건 | https://sabarada.tistory.com/26

REST API(RESTful API, 레스트풀 API)란? 구현 및 사용법 | https://www.redhat.com/ko/topics/api/what-is-a-rest-api

REST | https://ko.wikipedia.org/wiki/REST