[CS] RESTful API
서버를 공부하는 사람들이라면 RESTful API에 대해 들어봤을 것이다.
RESTful API란 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스를 말한다.
간단히 말해 REST의 특징을 기반으로 서비스 API를 구현한 것을 말한다.
그럼 여기서 말하는 REST란 무엇인가?
HTTP URI(Uniform Resource Identifier)를 통해 자원을 명시하고, HTTP Method(GET, POST, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
쉽게 구현하고 수정할 수 있어 모든 API 시스템을 파악하고 여러 플랫폼에서 사용할 수 있다.
즉, REST는 자원 기반의 구조(ROA) 설계 중심에 자원이 있고, HTTP Method를 통해 자원을 처리하도록 설계된 아키텍처를 말한다.
REST는 대강 알겠고, 그럼 API는 뭘까?
API는 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의한 것이다.
웹 API는 클라이언트와 웹 리소스 사이의 게이트웨이라고 생각하면 된다.
- 클라이언트 : 웹에서 정보에 액세스 하려는 사용자
- 리소스 : 다양한 애플리케이션이 클라이언트에게 제공하는 정보
API 개발자는 여러 아키텍처를 사용하여 API를 설계하는데, REST 아키텍처 스타일을 따르는 API를 REST API 라고 한다.
또한 REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스라고 한다.
RESTful API라는 용어는 일반적으로 RESTful 웹 API를 나타낸다.
하지만 REST API와 RESTful API라는 용어는 같은 의미로 사용할 수 있다.
REST 아키텍처 스타일의 원칙은 다음과 같다.
1. 균일한 인터페이스
모든 RESTful 웹 서비스 디자인의 기본이다. 이는 서버가 표준 형식으로 정보를 전송함을 나타낸다.
형식이 지정된 리소스를 REST에서는 표현 이라고 부른다.
균일한 인터페이스에는 4가지 아키텍처 제약 조건이 있다.
- 요청은 리소스를 식별해야 한다. 이를 위해 균일한 리소스 식별자를 사용한다.
- 클라이언트는 원하는 경우 리소스를 수정하거나 삭제하기에 충분한 정보를 리소스 표현에서 가지고 있다. 서버는 리소스를 자세히 설명하는 메타데이터를 전송하여 이 조건을 충족한다.
- 클라이언트는 표현을 추가로 처리하는 방법에 대한 정보를 수신한다. 이를 위해 서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메시지를 전송한다.
- 클라이언트는 작업을 완료하는 데 필요한 다른 모든 관련 리소스에 대한 정보를 수신한다. 이를 위해 서버는 클라이언트가 더 많은 리소스를 동적으로 검색할 수 있도록 표현에 하이퍼링크를 넣어 전송한다.
2. 무상태
서버가 이전의 모든 요청과 독립적으로, 모든 클라이언트 요청을 완료하는 통신 방법을 나타낸다.
클라이언트는 임의의 순서로 리소스를 요청할 수 있으며 모든 요청은 무상태이거나 다른 요청과 분리된다.
서버가 매번 요청을 완전히 이해해서 이행할 수 있음을 의미한다.
3. 계층화 시스템
계층화된 시스템 아키텍처에서 클라이언트는 클라이언트와 서버 사이의 중개자에게 연결할 수 있으며 서버로부터도 응답을 받는다.
서버는 요청을 다른 서버로 전달할 수도 있다.
클라이언트 요청을 이행하기 위해 함께 작동하는 보안, 애플리케이션 및 비즈니스 로직과 같은 여러 계층으로 여러 서버에서 실행되도록 RESTful 웹 서비스를 설계할 수 있다.
이러한 계층은 클라이언트에 보이지 않는 상태로 유지된다.
4. 캐시 가능성
서버 응답 시간을 개선하기 위해 클라이언트 또는 중개자에 일부 응답을 저장하는 프로세스인 캐싱을 지원한다.
캐시 가능 또는 캐시 불가능으로 정의되는 API 응답을 사용하여 캐싱을 제어한다.
5. 온디맨드 코드
서버는 소프트웨어 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확장하거나 사용자 지정할 수 있다.
예를 들어, 웹 사이트에서 등록 양식을 작성하면 브라우저는 잘못된 전화번호와 같은 실수를 즉시 강조 표시한다.
서버에서 전송한 코드로 인해 이 작업을 수행할 수 있다.
그럼 RESTful API를 사용하면 어떤 장점이 있을까?
1. 확장성
REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있다.
무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드를 제거한다.
잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거한다.
이러한 모든 기능은 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원한다.
2. 유연성
완전한 클라이언트-서버 분리를 지원한다. 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리한다.
서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않는다.
애플리케이션 함수를 계층화하는 기능은 유연성을 향상시킨다.
3. 독립성
사용되는 기술과 독립적이다. API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있다. 또한 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있다.
RESTful API의 동작 방식은 다음과 같다.
- 클라이언트가 서버에 요청을 전송한다. 클라이언트가 API 문서에 따라 서버가 이해하는 방식으로 요청 형식을 지정한다.
- 서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지 확인한다.
- 서버가 요청을 수신하고 내부적으로 처리한다.
- 서버가 클라이언트에 응답을 반환한다. 응답에는 요청이 성공했는지 여부를 클라이언트에 알려주는 정보가 포함된다. 응답에는 클라이언트가 요청한 모든 정보도 포함된다.
REST API 요청 및 응답 세부 정보는 API 개발자가 API를 설계하는 방식에 따라 차이가 있을 수 있다.
위의 동작 방식을 보면 궁금한 점이 두 가지가 있다. RESTful API 클라이언트 요청과 서버 요청에는 무엇이 포함되어 있을까?
| RESTful API 클라이언트 요청 | RESTful API 서버 요청 |
| 고유 리소스 식별자 | 상태표시줄 (HTTP 상태코드) |
| 메소드 | 메세지 본문 |
| GET | 헤더 |
| POST | |
| PUT | |
| DELETE | |
| HTTP 헤더 | |
| 데이터 | |
| 파라미터 |
REST API를 만들었다고 해놓고서는 정작 REST API가 무엇인지 정확히 모르는 것 같아 정리해봤다.
생각보다 개념이 복잡한 것 같지만 공부해보니 웬만하면 다 아는 것들이었다.
그리 어렵지 않으니 다들 자세히 공부해보는 걸 추천!