API (Application Programming Interface)
다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의한 것이다. 웹 API는 클라이언트와 웹 리소스 사이의 게이트웨이라고 할 수 있다.
Google Maps API를 예로 들자면
지도 API는 웹 또는 모바일 애플리케이션에서 지도 데이터를 안전하게 가져오고 사용할 수 있게 해주는 인터페이스이다.
사용자가 특정 위치를 검색하면, 클라이언트는 Google Maps 서버에 HTTP 요청을 보낸다. 이 요청은 사용자의 검색어와 함께 보내지며 주소, 좌표, 또는 특정 장소의 이름일 수 있다. HTTPS 요청을 통해 암호화되어, 정보가 안전하게 전송된다. 또한 API 키가 포함되어 있어 Google Maps 서버가 요청을 보낸 클라이언트를 인식할 수 있는 것이다.
상태가 없음(Stateless)? 이게 왜 중요한가?
각 요청이 독립적으로 처리되며, 서버는 이전 요청에 대한 정보를 저장하거나 유지할 필요가 없다. ⇒ 각 요청이 자체적으로 모든 필요한 정보를 포함하고 있다. 따라서 서버가 클라이언트의 상태를 추적할 필요가 없으므로, 서버의 복잡성을 줄이고 오류를 더 쉽게 피할 수 있다.
REST(Representational State Transfer)
API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처로, REST는 처음에 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어졌다. 쉽게 구현하고 수정할 수 있어 모든 API 시스템을 파악하고 여러 플랫폼에서 사용할 수 있다.
API 개발자는 여러 아키텍처를 사용해 API를 설계할 수 있는데, REST 아키텍처 스타일을 따르는 API를 RESTful API라고 한다.
RESTful API란?
- 고객(클라이언트) → 통신을 시작하는 사용자 측
- 서버 → API를 기능 및 데이터에 대한 액세스로 사용하는 서버
- 자원 → 서버가 클라이언트에 전송하는 모든 콘텐츠(비디오, 텍스트, 사진)
자원
SON, HTML, XLT, Python 또는 일반 텍스트와 같은 다양한 형식으로 클라이언트에 전달할 수 있다. 가장 인기있고 주로 사용되는 JSON 형식은 사람과 기계가 읽을 수 있고, 언어에 구애받지 않기 때문에 JSON이다.
엔드포인트
리소스를 찾을 수 있는 방법과 위치를 나타내는 URI가 포함되어 있다.
헤더
클라이언트 및 서버와 관련된 데이터가 포함된다. 헤더에는 인증 데이터(API 키, 이름, 서버가 설치된 컴퓨터에 속하는 IP 주소, 응답 형식에 대한 정보)가 포함된다.
본문
추가하려는 데이터와 같은 추가 정보를 서버에 보내는 데 사용된다.
RESTful API의 4가지 원칙
| 조건 | 설명 |
|---|---|
| 균일한 인터페이스 | 요청은 리소스를 식별하고, 클라이언트가 원하는 경우 리소스를 수정 및 삭제하기에 충분한 리소스를 표현에서 가지고 있다. |
| 무상태 | 이전의 모든 요청과 독립적으로 모든 클라이언트의 요청을 완료하는 통신 방법을 나타낸다. 임의의 순서로 리소스를 요청할 수 있으며, 모든 요청은 무상태 혹은 다른 요청과 분리된다. 즉, 클라이언트의 요청을 서버가 매번 완전히 이해해서 수행할 수 있음을 의미한다. |
| 계층화 시스템 | 클라이언트 ↔ 서버 사이의 다른 승인된 중개자에게 연결할 수 있다. 그리고 여전히 서버로부터 응답받을 수 있다. |
| 캐시 가능성 | 응답 시간을 개선하기 위해 클라이언트 혹은 중개자에게 일부 응답을 저장하는 프로세스인 캐싱을 지원한다. 공통 헤더/푸터가 있는 페이지를 접속한다고 가정했을 때, 이 이미지를 다시 전송해야 한다. 이를 피하기 위해 첫 번째 응답 후 해당 이미지를 캐싱하거나 저장한 다음 직접 이미지를 사용한다. |
| 온디맨드 코드 | 서버는 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확장하거나 사용자 지정할 수 있다. |
😟 캐싱 ↔ 무상태 그 사이
| 캐싱 | 데이터나 정보를 빠르게 접근하기 위해 임시로 저장하는 과정이다. 표적으로 웹 브라우징 시에 웹페이지의 정보를 임시로 저장해두었다가, 다시 해당 웹 페이지를 방문할 때 빠르게 로딩하여 사용자 경험(UX)를 향상시키는 방법으로 사용된다. |
|---|
내가 이해가 안 됐던 것은 캐싱과 무상태 원칙
캐싱으로 서버의 응답을 임시로 저장하는데, 무상태 원칙을 준수하면서 클라이언트의 모든 요청을 독립적으로 수행한다? → 이건 명백히 다른 관점이다. 서버는 여전히 각 요청을 독립적으로 처리하며, 이전 요청에 대한 정보를 기억할 필요가 없다. → 그럼에도 불구하고, 클라이언트는 서버의 응답을 캐싱(임시 저장)한다. 캐싱 프로세스는 서버에서 발생하는 것이 아니라 클라이언트에서 발생하므로, 서버의 요청 처리 방식에는 영향을 미치지 않는다.
RESTful API 사용 시의 이점
| 이점 | 설명 |
|---|---|
| 확장성 | 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정을 할 수 있다. ‘무상태’는 서버가 과거의 클라이언트 요청을 잊기 떄문에, 서버 로드를 줄일 수 있다. |
| 유연성 | 클라이언트-서버의 분리를 지원한다. 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성요소를 단순화하고 분리한다. |
| 독립성 | 사용되는 기술과는 독립적이다. API 설계에 영향을 주지않고 다양한 언어로 클라이언트와 서버 어플리케이션을 모두 작성할 수 있다. |
RESTful API는 어떻게 작동하는가?
| 메소드 | 기능 |
|---|---|
| GET | 서버의 지정된 URL에 있는 리소스에 액세스 |
| POST | 서버에 데이터를 전송 |
| PUT | 서버의 기존 리소스 업데이트 |
| DELETE | 서버의 기존 리소스 제거 |
📃 ref doc
