API 또는 응용 프로그래밍 인터페이스는 서로 다른 응용 프로그램 간의 상호 작용 및 통신을 허용하는 기능과 규칙을 제공합니다. 이러한 인터페이스는 애플리케이션 통합을 용이하게 하여 개발자가 강력한 디지털 제품을 만들 수 있도록 합니다.
API는 요청과 응답을 통해 애플리케이션 사이를 중재합니다. 예를 들어, 사용자의 기존 Twitter 계정을 통한 애플리케이션 등록은 개발자가 앱에 통합한 Twitter API를 통해 발생합니다. 
- XML-RPC — 네트워크 간의 기능 교환을 허용합니다. XML-RPC는 XML을 사용하여 클라이언트에서 서버로 정보를 전송하기 위한 응답/요청 및 HTTP 프로토콜을 설명합니다.
- JSON-RPC는 XML과 유사한 경량 RPC입니다. 여기서 프로토콜은 JSON으로 인코딩됩니다. 비동기 응답으로 서버에 대한 호출을 수신할 수 있습니다.
- SOAP — 컴퓨터 네트워크에서 웹 서비스를 구현할 때 구조화된 정보를 교환하기 위한 간단한 개체 액세스 프로토콜입니다. SOAP는 운영 체제에서 인증, 권한 부여 및 프로세스 통신을 위해 XML을 사용합니다. 플랫폼과 언어에 관계없이 클라이언트가 웹 서비스를 호출하고 응답을 받을 수 있습니다.
- REST API(대표 상태 전송) — 클라이언트-서버 구현을 독립적으로 사용하는 아키텍처 스타일입니다. REST는 통신에 HTTP 프로토콜을 사용합니다.
이 포스트에서는 REST API에 초점을 맞춰 정의하고, 다른 API와 어떻게 다른지 분석합니다.
REST API 정의
REST는 HTTP 프로토콜을 통해 API를 설계하기 위한 아키텍처 스타일입니다. 주요 이점은 뛰어난 유연성입니다.
개발자는 서버에서 직접 웹 애플리케이션이나 사이트의 사용자에게 데이터를 제공해야 하는 모든 곳에서 REST API를 사용합니다. 
- 고객 — 통신을 시작하는 사용자 측(자신의 장치에서)에서 시작된 클라이언트 또는 프로그램.
- 섬기는 사람 — API를 기능 및 데이터에 대한 액세스로 사용하는 서버.
- 자원 — 서버가 클라이언트에 전송하는 모든 콘텐츠(비디오, 텍스트, 사진).
REST API 작동 방식
REST API는 HTTP 요청을 통해 통신하여 데이터 생성, 읽기, 업데이트 및 삭제 기능을 완료합니다. CRUD 작업이라고도 합니다. REST는 요청된 리소스에 대한 정보를 제공하고 리소스로 수행할 작업을 설명하는 네 가지 방법을 사용합니다.
POST — 리소스 생성
GET — 리소스 가져오기
PUT — 리소스 업데이트
DELETE — 리소스를 삭제합니다.
자원
리소스는 정보 추상화인 REST API에서 중요한 개념입니다. 문서, 이미지, 임시 서비스와 같은 모든 정보가 될 수 있습니다.
주어진 순간의 리소스 상태는 데이터, 데이터를 설명하는 메타데이터, 고객이 다음 상태로 이동하는 데 도움이 되는 하이퍼미디어 링크로 구성된 리소스 표현으로 알려져 있습니다.
정보는 JSON, HTML, XLT, Python 또는 일반 텍스트와 같은 다양한 형식으로 클라이언트에 전달할 수 있습니다. 가장 인기 있고 사용되는 JSON은 사람과 기계가 읽을 수 있고 언어에 구애받지 않기 때문에 JSON입니다.
리소스에 액세스하려면 클라이언트가 요청해야 합니다. 수신 후 서버는 리소스에 대한 인코딩된 데이터로 응답을 생성합니다.
요청 구조에는 HTTP 메서드(앞서 언급한 CRUD), 엔드포인트, 헤더 및 본문의 네 가지 주요 구성 요소가 포함됩니다.
HTTP 메서드 는 리소스로 수행해야 하는 작업을 설명합니다. 바로 위에서 POST, GET, PUT, DELETE의 네 가지 사용 가능한 방법을 언급했습니다.
끝점 에는 리소스를 찾을 수 있는 방법과 위치를 나타내는 URI(Uniform Resource Identifier)가 포함되어 있습니다. URL 또는 Uniform Resource Location은 전체 웹 주소를 나타내는 가장 일반적인 URI 유형입니다.
헤더 에는 클라이언트 및 서버와 관련된 데이터가 포함됩니다. 헤더에는 인증 데이터(API 키, 이름, 서버가 설치된 컴퓨터에 속하는 IP 주소, 응답 형식에 대한 정보)가 포함됩니다.
본문 은 추가하려는 데이터와 같은 추가 정보를 서버에 보내는 데 사용됩니다.
REST API 원칙
REST는 특정 기술이나 플랫폼에 얽매이지 않습니다. 그것은 언어 독립적입니다. 또한 API를 빌드하는 방법을 정확하게 지정하지 않습니다. 그러나 6가지 아키텍처 제약 조건을 사용합니다. 이러한 제약 조건에 따라 인터페이스를 유효한 REST API라고 부를 수 있습니다. 서버가 요청을 처리하고 응답하는 방법을 설명합니다.
클라이언트 서버
REST API는 클라이언트-서버 아키텍처 스타일을 구현합니다. 클라이언트가 리소스에 대한 요청을 보내고 있으며 데이터 저장소와 연결되어 있지 않습니다. 데이터 저장소는 서버 내부에 남아 있습니다. 서버는 사용자 인터페이스와의 통신에 관여하지 않습니다. 클라이언트와 서버는 상호 의존적으로 발전합니다. 이 요소는 REST를 훨씬 더 유연하고 확장 가능하게 만듭니다.
균일한 인터페이스
통합 인터페이스는 REST API를 구별하는 필수 요소입니다. 응용 프로그램 및 장치 유형을 의미하는 것이 아니라 서버와 통신하는 단일 방법이 있음을 나타냅니다.
균일한 인터페이스에는 4가지 원칙이 있습니다.
- 자원 식별. 각 리소스에는 리소스 상태와 독립적인 ID가 있어야 합니다. URL은 식별자 역할을 합니다.
- 표현을 통한 자원 조작. 클라이언트가 가지고 있는 리소스 표현에는 리소스를 삭제하거나 수정하는 데 필요한 데이터가 포함됩니다. 클라이언트는 서버(JSON 객체)가 수정, 제거 또는 추가해야 하는 표현을 보냅니다.
- 자기 설명 메시지. 이러한 메시지에는 수신자가 이해할 수 있도록 모든 정보가 포함되어 있습니다. 별도의 문서나 메시지에는 추가 정보가 필요하지 않습니다. 각 메시지에는 서버가 요청을 구문 분석할 수 있는 충분한 정보가 있습니다.
- 애플리케이션 상태의 엔진으로서의 하이퍼미디어. Hypermedia는 클라이언트가 다른 리소스를 찾을 수 있도록 각 응답에 대한 링크 사용이 필요합니다. REST에서 하이퍼미디어는 모든 상호작용에 사용됩니다.
무국적자
서버에 클라이언트에 대한 데이터가 포함되어 있지 않음을 의미합니다. 요청 처리에 필요한 모든 정보가 요청에 포함됩니다. 클라이언트는 모든 세션 정보를 저장합니다.
캐시 가능
각 응답에는 캐시 가능 여부와 응답을 캐시할 수 있는 기간을 알려주는 정보가 있어야 합니다. 캐시 가능한 경우 유사한 요청에서 클라이언트는 서버에 반복적으로 요청을 보내지 않고도 동일한 데이터를 사용할 수 있습니다. 성능과 가용성을 개선하는 데 도움이 됩니다.
계층화 시스템
REST는 구성 요소의 동작에 대한 특정 제한을 생성하는 계층 계층을 구현합니다. 계층화된 시스템에서 구성 요소는 가장 가까운 수준에 있는 구성 요소와 상호 작용하는 구성 요소만 볼 수 있습니다.
주문형 코드
클라이언트가 코드를 다운로드하고 실행할 수 있도록 하는 선택적 기능입니다.
REST API의 차이점은 무엇입니까?
REST API의 6가지 원칙은 이 인터페이스와 다른 유형 간의 주요 차이점으로 간주될 수 있습니다. 또한 여러 매개변수가 REST를 구별합니다.
첫째, REST의 본질은 다른 유형과의 비호환성을 결정합니다. 아키텍처가 RESTful 웹 서비스를 제공하기 위해 따라야 하는 일련의 요구 사항을 나타내는 아키텍처 스타일입니다. 예를 들어 SOAP 및 RPC는 메시지를 설명하는 메시징 프로토콜입니다. 메시지가 충족해야 하는 요구 사항(제약 사항)만 지정하는 아키텍처 스타일과 다릅니다.
구조
일반적으로 API는 앱 대 앱 형식을 따르는 반면 REST는 다른 구조(클라이언트-서버)를 따릅니다. 클라이언트와 서버는 독립적으로 발전하여 작업에 더 많은 유연성을 제공합니다.
메시지 교환 형식
API는 일반적으로 특정 메시지 형식을 사용합니다. 예를 들어 SOAP는 XML을 사용합니다. REST는 그런 엄격한 원칙을 따르지 않습니다. 거의 모든 형식을 사용하여 데이터를 교환할 수 있습니다. 그러나 이제 JSON이 가장 인기 있는 것입니다.
JSON의 인기 뒤에는 분명한 이유가 있습니다. 사람이 읽을 수 있고 데이터 교환 형식을 쉽게 분석할 수 있습니다. JSON은 언어 독립적이며 JavaScript 이외의 모든 언어와 함께 사용할 수 있습니다.
유연성
REST는 유연한 아키텍처 스타일이므로 개발자가 널리 사용합니다. 더 많은 대역폭을 필요로 하는 고급 보안 기능이 있는 더 복잡한 프로토콜인 SOAP와 비교할 때 REST는 개발자가 해당 형식으로 이러한 요구 사항을 사용할 수 있도록 하는 간단한 지침으로 구성됩니다. 이 아키텍처는 고성능을 제공하므로 다운로드 속도가 중요한 모바일 장치에 특히 적합합니다.
보시다시피 REST는 알려진 다른 API에 비해 몇 가지 장점이 있습니다. 그렇기 때문에 Twitter 및 Google과 같은 모든 주요 회사는 제품에 이 기능을 구현했습니다. 결국 이는 전 세계 개발자에게 데이터를 전송하는 이상적이고 쉬운 방법이며 소프트웨어 개발을 위한 효율적이고 확장 가능한 인터페이스를 생성하기 위한 입증된 메커니즘입니다.
