[API] REST API에 대해서

API는 클라이언트와 서버간의 약속으로 이루어집니다.

클라이언트가 서버로 응답을 보낼 때는 정해진 양식을 준수하여 보내야 하며,

서버 또한 올바른 응답을 클라이언트에게 전송해 주어야 합니다.
때문에 API 디자인 원칙을 얼마나 잘 세우느냐가 통신 성능에 큰 영향을 줄 수 있습니다.

REST(REpresentational State Transfer) API는 이러한 API 디자인 원칙 중 하나로,

특별한 이름을 부여한 자원들의 상태를 주고받는 방법에 대한 규칙입니다.

REST API는 Web과 HTTP 프로토콜의 기능을 최대한 활용할 수 있도록 설계된 디자인 원칙으로,

크게 아래 여섯 가지의 특징을 가지고 있습니다.

API를 이용해 정보를 교환하는 두 시스템은 클라이언트와 서버의 관계로 이루어져야 합니다.

클라이언트와 서버는 서로 독립적인 시스템이기 때문에 API 통신 외에는 의존성을 가지지 않습니다.

클라이언트와 서버는 상태를 저장하지 않습니다.

서버는 클라이언트 요청와 관련된 데이터를 따로 저장할 수 없기 때문에,

각 요청에는 처리에 필요한 모든 정보가 포함되어야 합니다.

통신에 자주 사용하는 데이터를 캐시 메모리에 저장하여 보다 빠르게 접근할 수 있도록해야 합니다.

이에 대해서 요청은 '응답이 캐시 가능한지에 대한 여부'를 명시해야 합니다.

API는 일관된 인터페이스를 제공해야 합니다.

이는 요청의 출처(클라이언트 종류)와 관계 없이 API 요청은 같은 형식으로 나타나야 한다는 의미입니다.

인터페이스가 일관되면 서버 또는 클라이언트 한 쪽이 업데이트되어도 나머지 한 쪽을 함께 업데이트할 필요가 없어집니다. 이를 결합도가 낮다라고 표현합니다.

일반적으로 클라이언트와 서버는 직접 연결되지 않고, 그 사이에 다양한 중개자가 있을 수 있습니다.

그럼에도, 클라이언트는 서버에 직접 연결되어 있는지 또는 중간 서버를 통해 연결되어 있는지 알 수 없어야 합니다.

서버에서 보낸 동적 코드(e.g. JavaScript)를 클라이언트에서 실행할 수 있어야 합니다.

이는 선택 사항으로, REST API를 위한 필수 조건은 아닙니다.

사실 이 모든 제약을 지키면서 API를 디자인하기는 어렵습니다.

가능하다고 해도 비용과 시간 대비 얻을 수 있는 효과가 그렇게 뛰어나지도 않죠.

때문에 대부분의 API는 이 REST 조건의 일부만을 채용해서 구현하고, 이런 종류의 API를 RESTful API라고 합니다.

대표적인 예시로 HTTP 프로토콜을 이용한 웹 서비스는 일관된 인터페이스를 제외한 거의 모든 조건을 지키면서 구현할 수 있습니다.

REST 조건	HTTP
클라이언트 - 서버 분리	웹 서비스는 클라이언트와 서버 구조를 가지고 있습니다.
무상태성	무상태성과 비연결성을 가집니다.
캐시 가능성	헤더의 Cache-Control 속성으로 캐시 가능 여부를 명시합니다.
계층화된 시스템 구조	요청과 응답을 보내는 주체는 중간 계층을 고려하지 않아도 됩니다.
주문형 코드	서버는 <body> 요소에 코드를 담을 수 있습니다.

마지막 남은 일관된 인터페이스는 보통 '요청을 보낼 때 무엇을 어디로 어떻게 보낼지'에 대한 조건인데,

여기서도 크게 네 가지 조건이 요구됩니다.

728x90

상태코드 정리 (0)	2024.08.01
[API] REST - 표현을 통한 자원에 대한 조작: HTTP Method (0)	2024.08.01
[API] REST - 자원에 대한 식별: URI 표기법 (0)	2024.08.01
[API] API에 대해서 (0)	2024.07.30
[API][Stripe] Stripe에 대해서 (0)	2024.07.05

티스토리툴바