API, HTTP API, REST API 차이

김윤준·2024년 4월 4일
post-thumbnail

참고 사이트

API를 너무 형식적으로 기억해와서 정확한 정의가 무엇인지 알고싶어 필기함.

내가 아는 API
: 서버에서 어떠한 정보를 제공해주거나 받기위해 만들어둔 약속 같은 것.


API (Application Programming Interface)

인터페이스(Interface) : 사물과 인간 사이의 경계에서 상호 간의 소통을 위해 만들어진 물리적 매개체나 프로토콜.
ex) TV 리모콘 전원 버튼은 인터페이스. 사람이 버튼을 눌러 TV가 켜지도록 연결하는 매개체이기 떄문

API는 애플리케이션(응용프로그램)에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻함.

즉, 애플리케이션이 어떤 프로그램이 제공하는 기능을 사용할 수 있게 만든 매개체

컴퓨터와 인간을 연결시키는 사용자 인터페이스(UI)와는 반대로, API는 컴퓨터나 소프트웨어를 서로 연결한다.

서버는 프로그램에게 자신이 제공하고자 하는 데이터나 기능을 제어할 수 있는 API로 만들면, 접근 권한이 있는 프로그래머나 프로그램이 API를 통해 서버에서 제공하는 데이터를 요청해서 사용할 수 있게 된다.

ex) 날씨 정보 앱을 만들려면, 기상청 서버가 제공하는 API에 원하는 날씨 정보를 요청하고 데이터를 받아 사용자에게 제공함.

API의 한가지 목적은 서버 시스템이 동작하는 방식에 관한 내부 프로세스를 숨기는 것으로, 내부의 세세한 부분이 나중에 변경되더라도 프로그래머가 유용하게 사용할 수 있고 일정하게 관리할 수 있는 부분들만 노출시킨다.


HTTP API

HTTP 프로토콜을 사용하여 통신하는 API.

주로 웹 서비스에서 클라이언트와 서버간의 데이터 교환을 위해 사용됨.

HTTP 메소드(GET, POST, PUT, DELETE 등)를 사용하여 리소스에 접근하고, 이를 통해 기능을 사용할 수 있게 함.
👉 HTTP 메소드

HTTP API는 RESTful 일수도 있고, 그렇지 않을 수도 있다.

RESTful : REST의 원리를 따르는 시스템.
REST를 사용했다고 해서 모든게 RESTful 한건 아님.
ex) HTTP 메소드를 사용했다고 해서 crud 기능을 모두 post로 처리한다던데 URI 규칙을 올바르게 지키지 않았다던가 하는 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 RESTful 하지 못한 시스템이라고 할 수 있다.


REST API

HTTP API의 설계에 있어서 특정한 규칙을 따르는 API 형태.

💡규칙

1. Client-Server 구조 : 클라이언트와 서버가 독립적으로 분리되어야함.
2. Stateless : 각 요청은 독립적이며, 이전 요청의 상태 정보를 저장하지 않는다.

  • 세션, 쿠키 정보를 저장하지 않기 때문에 API 서버는 들어오는 요청만 단순히 처리하면 된다. 이러한 이유로 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.

3. Cacheable : 클라이언트는 응답을 캐싱할 수 있어야 하며, 이를 통해 상호작용 할 수 있어야 한다.
4. Uniform Interface : URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 의미한다.
5. Layered System (계층화) : REST 서버는 다중 계층으로 구성 될 수 있으며, 로드 밸런싱, 암호화 계층을 추가해 구조 상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있게 한다.

⚠️ REST의 장단점

장점
1. REST API 메시지가 의미를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
2. 서버와 클라이언트의 역할을 명확히 분리
3. 캐싱 가능: REST API 응답은 캐싱 가능하므로, 네트워크 대역폭을 줄이고 성능 향상 가능. 캐싱이란?
단점
1. 상태 관리의 어려움 : 상태가 없는 특성은 서버가 이전 요청의 상태를 기억하지 않기 떄문에 복잡한 트랙잭션이나 세션 관리가 어려울 수 있다.
2. REST는 아키텍처 스타일이기 때문에 엄격한 표준이 없다.


국내 유일무의 개발자 1티어 강사

"김영한" 님의 말씀 중

HTTP API와 REST API는 사실 거의 같은 의미로 사용된다 함.
정확한 차이점으로 REST API는 HTTP 프로토콜을 따르면서 아래의 4가지 가이드 원칙을 지켜야 한다.

1) 자원의 식별
2) 메시지를 통한 리소스 조작
3) 자기서술적 메세지
4) 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어

이러한 제약 조건을 완벽하게 지키면서 개발하는 것을 RESTful API 라고 한다.
(실무에선 위 방법을 지키면서 개발하는 것은 현실적으로 어렵하고 한다.)
그러나 위 조건을 전부 지키지 않아도 REST API라고 하기 때문에 HTTP API와 같은 의미로 사용하고 있다고 한다.

하지만 위 제약을 전부 지키면 본연의 REST API라고 할 수 있을듯.

0개의 댓글